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.

HANDOFF.md

@@ -1,11 +1,12 @@
 # HANDOFF — 2026-10-21 (the creator's three properties-panel asks shipped; the vv webcam Units 1+2 state below)
 
 ## At a glance
-- **Branch** main, tracking `origin/main`. **HEAD = `6271bf3` — origin/main is still `3a77662`, so
-  three commits are waiting to be pushed** (TASK 58 the theme sweep, TASK 59 the properties
-  hierarchy, TASK 60 the colour names — the creator's three property-panel asks, done in one
-  batch). **Not pushed yet:** the push happens at a sub-milestone/milestone or at the creator's
-  word ("push it") — the creator has not said so for this batch.
+- **Branch** main, tracking `origin/main`. **origin/main is still `3a77662`, so five commits are
+  waiting to be pushed** (TASK 58 the theme sweep, TASK 59 the properties hierarchy, TASK 60 the
+  colour names, a docs commit, and TASK 61+62 the geometry field widths and the colour name beside
+  the hex — the creator's properties-panel asks, done in one batch). **Not pushed yet:** the push
+  happens at a sub-milestone/milestone or at the creator's word ("push it") — the creator has not
+  said so for this batch.
   - The vv feature (Units 1+2) **was** pushed at its close (2026-10-21 — the creator approved
     the Unit 1 push after testing it, and the completed feature is a milestone).
   - **The push path changed:** `origin` is now
@@ -43,6 +44,15 @@
   moved out of the click handler into `Models/BorderColorPalette.cs` (`NamedColor(Hex, Name)` +
   `NameOf(hex)`), so the list is testable and extensible. Guard:
   `ytLive.Tests/BorderColorPaletteTests.cs`.
+- **TASK 61 + 62 — the geometry fields and the border-colour field** (shipped 2026-10-21).
+  - **61:** the X/Y/W/H fields share ONE fixed width (44px — the largest geometry value, 1920,
+    plus a sign) and their rows set `LastChildFill="False"`, so Y/H no longer stretch to fill
+    the row while X/W sized themselves to their text. Guard: `ytLive.Tests/GeometryFieldWidthTests.cs`
+    (it MEASURES the widest value with WPF's `FormattedText` — measure, don't guess).
+  - **62:** the border-colour field shows the palette's **name beside the hex**
+    (`SceneElement.BorderColorName`, empty for a custom hex), and the hex field keeps a fixed
+    width so the name stays next to the hex. The field stays editable (a custom hex can
+    still be typed). Guard: `ytLive.Tests/BorderColorNameTests.cs`.
 - **The previous session (HA lights) produced NO ytLive code** — it was spent on the creator's Home
   Assistant light alert system (off-repo, `192.168.50.145`). See `MyMistakes.md` → 2026-10-21: the plan
   was one tweak to a verified-working script; the script was rewritten twice, the alert path broke, and
@@ -188,6 +198,10 @@ Zombie entities deleted from the registry: `script.leak_strobe`, `script.doorbel
 - Nothing else is queued for llamacasty — the creator queues work.
 
 ## Open (operational)
+- **Follow-up (not fixed — out of scope for TASK 61):** the **web source** block's geometry rows in
+  `Controls/LeftPanel.xaml` (the `SelectedElement.IsWebSource` panel, ~lines 387-402) have the
+  identical shape and the identical defect as the webcam's did — the Y/H fields stretch to fill the
+  row. Same one-line-per-field fix as TASK 61, when the creator wants it.
 - **Follow-up spotted while doing TASK 60 (not fixed — out of scope for that change):** the border
   colour swatches in the drop-down are a plain `Border` with the colour as `Background` and **no
   border**, so the black (`#000000`) and dark swatches are nearly invisible against the dark menu
@@ -216,10 +230,10 @@ Zombie entities deleted from the registry: `script.leak_strobe`, `script.doorbel
 - TASK 55 disk hygiene (`startup.log` uncapped — 23MB and growing every 5s).
 
 ## Tests
-- Last full run: **433/433 passed, 0 warnings** (2026-10-21, this session — after TASK 60's
-  `BorderColorPaletteTests`; the runs before it were 432/432 after TASK 59 and 431/431 after
-  TASK 58). The one failure seen earlier in the session was
-  `LayerReorderPersistenceTests.RealMouseDrag_OnTheLayerList_PersistsTheReorder`,
+- Last full run: **435/435 passed, 0 warnings** (2026-10-21, this session — after TASK 61's
+  `GeometryFieldWidthTests` and TASK 62's `BorderColorNameTests`; the runs before were 433/433 after
+  TASK 60, 432/432 after TASK 59 and 431/431 after TASK 58). The one failure seen earlier in the
+  session was `LayerReorderPersistenceTests.RealMouseDrag_OnTheLayerList_PersistsTheReorder`,
   which **passes in isolation** (re-run: 3/3) — the known real-mouse flake, not a regression.
 - Known flaky-by-environment (all pass in isolation): `AudioPipelineTests.Mix_HonorsProviderGains…`,
   `MasterLimiter_CapsTheLiveMix_OnThePipe`, `LayerReorderPersistenceTests.RealMouseDrag…`,