TASK 61 + 62: the geometry fields share one width, and the border field names its colour

The creator (2026-10-21), on Live -> Layers -> webcam -> Properties:

  "the Y and H boxes under webcam properties should be the same width as the X and W
   boxes and those widths should be fixed to accomodate the max number of possible
   digits providing the geometry values"

  "also the border color drop drown box content should also include the name of the
   color next to the hex value as they in the drop-down list box"

TASK 61 - one fixed width for the four geometry fields.
The row is a DockPanel, and WPF sizes an element to its CONTENT unless it is told
otherwise, while the LAST child of a DockPanel fills the remaining space. So X/W (not
last) were as wide as their text and Y/H (last) stretched across the row - two widths
for the same kind of field. Now all four carry Width="44" and the rows set
LastChildFill="False" (without it the last field ignores its own Width and fills anyway).
44px is the measured width of "-1920" in the app's font at 11px (the largest geometry
value - the master frame is 1920x1080 - plus a sign) plus the field's padding and
border. Docs: https://learn.microsoft.com/en-us/dotnet/api/system.windows.controls.dockpanel.lastchildfill
The guard MEASURES the widest value with WPF's FormattedText instead of asserting a
magic number, so a font change cannot silently make the field too narrow:
https://learn.microsoft.com/en-us/dotnet/api/system.windows.media.formattedtext

TASK 62 - the border field names its colour.
SceneElement.BorderColorName carries the palette's name for the current colour
("Crimson") and is raised when the colour changes; it is EMPTY for a custom hex the
creator typed, because "no name" is the honest answer. BorderColorPalette.NameOf
changed to match (it used to fall back to the hex itself; the TASK 60 test assertion
was updated with it). The hex field keeps a fixed width (60) so the name sits right
next to the hex instead of drifting to the row's far edge - the same trap as TASK 61.

Guards: ytLive.Tests/GeometryFieldWidthTests.cs, ytLive.Tests/BorderColorNameTests.cs
Full suite: 435/435 passed, 0 warnings.

TASKS/task-61-geometry-field-widths.md

@@ -0,0 +1,43 @@
+# TASK 61 — The geometry fields share one fixed width
+
+**Status:** ✅ Done — shipped 2026-10-21.
+
+## What it is
+The creator (2026-10-21), on Live → Layers → webcam → Properties → **Geometry**:
+
+> the Y and H boxes under webcam properties should be the same width as the X and W boxes
+> and those widths should be fixed to accomodate the max number of possible digits
+> providing the geometry values
+
+## Why they looked different
+The row is a `DockPanel`:
+
+```
+[X label][X field][  Y label][Y field]
+```
+
+A WPF element **sizes itself to its content** unless it is told otherwise, and in a
+`DockPanel` the **last child fills the remaining space**. So the X/W fields (not last)
+were as wide as their text ("1920" ≈ 34px) while the Y/H fields (last) stretched to the
+full width of the row — two different widths for the same kind of field.
+
+## The fix
+- **All four fields carry the same explicit `Width="44"`** — wide enough for the largest
+  geometry value (the master frame is 1920×1080 → four digits) **plus a sign** the creator
+  may be typing, and no wider.
+- **The rows set `LastChildFill="False"`** — otherwise the last field would still stretch
+  to the row's width regardless of its own `Width`.
+
+44px = the measured width of `-1920` in the app's font at 11px (≈28px) + the field's
+padding (8) + its border (2) + slack.
+
+## The test
+`ytLive.Tests/GeometryFieldWidthTests.cs` — the ONE test for this change: the four
+fields carry the same **explicit** width (no field sizes itself to its content), and that
+width really fits the widest value — measured with WPF's `FormattedText` in the app's own
+font (`SystemFonts.MessageFontFamily`) at the field's 11px, plus the padding and border.
+
+## Not done (out of scope, noted in `HANDOFF.md`)
+The **web source** block's geometry rows (`Controls/LeftPanel.xaml`, the
+`SelectedElement.IsWebSource` panel) have the identical shape and the identical defect —
+same fix, one line each, when the creator wants it.

TASKS/task-62-border-colour-name-in-the-field.md

@@ -0,0 +1,42 @@
+# TASK 62 — The border-colour field shows the colour's name next to the hex
+
+**Status:** ✅ Done — shipped 2026-10-21.
+
+## What it is
+The creator (2026-10-21), on Live → Layers → webcam → Properties → **Border Color**,
+after TASK 60 gave the drop-down list its names:
+
+> the border color drop drown box content should also include the name of the color next
+> to the hex value as they in the drop-down list box
+
+So the row that shows the **current** colour now reads the same way the list rows do:
+
+```
+Border Color
+  [#2c3a5c]  Azure   [...]
+```
+
+## How it is done
+- **`SceneElement.BorderColorName`** — the palette's name for the current border colour,
+  raised whenever `BorderColor` changes. **Empty for a custom hex** the creator typed
+  (there is no name for it — the field shows the hex alone).
+- The **hex field keeps a fixed width** (`Width="60"`): it used to fill the row, so a name
+  beside it would have drifted to the far edge instead of sitting next to the hex.
+- The name is a dimmed `TextBlock` (`#a0a0b0`, 11px) in the same horizontal row as the
+  field, after it — the same reading order as the drop-down list (`#e94560  Crimson`).
+
+**The field stays editable** — the hex is still typed into it (the picker's `...` button
+opens the named list). Making the field read-only with a combined "#hex  Name" string was
+the alternative; it would have taken away typing a custom hex, so the name sits beside
+the field instead.
+
+## `BorderColorPalette.NameOf` changed
+It used to fall back to **the hex itself** for a colour outside the palette ("there is no
+name to give it"). It now returns an **empty string** — "no name" is the honest answer,
+and the caller decides what to show (the field shows the hex alone). The TASK 60 test
+assertion was updated with it.
+
+## Tests
+`ytLive.Tests/BorderColorNameTests.cs` — the ONE test for this change: the model carries
+the name ("Crimson") and raises it when the colour changes, a custom hex has no name, the
+hex field has a fixed width, and the name sits in the same row as the field, after it.