TASK 60: the border-colour drop-down names every colour

The creator: "under Live->Layers->webcam->Properties->border color: in the drop
down box, the #hex values are good, but add a corresponding color name/label next
to the value."

Each row now reads "#e94560  Crimson" - the hex stays exactly as it was, the
colour's name goes next to it (dimmed #a0a0b0 so the hex reads first), and the
tooltip becomes "Crimson (#e94560)".

The 14 colours were a hard-coded string[] inside the click handler - a list of
bare strings cannot carry a name, and a list hidden in UI code cannot be asserted
on. They now live in Models/BorderColorPalette.cs: NamedColor(Hex, Name) +
BorderColorPalette.All (the single source of truth) + NameOf(hex), which answers
case-insensitively and falls back to the hex for a colour outside the palette.
The picker builds its menu from the catalogue and no longer knows any colour by
heart.

The names are chosen not to collide - the palette has two greens, two blues and
two warm colours: #00FF00 is Lime and #22c55e Emerald, #0000FF is Blue and
#3b82f6 Azure, #FF8800 is Orange and #f59e0b Amber.

Guard: ytLive.Tests/BorderColorPaletteTests.cs - every entry valid + named, no
hex or name repeated, the 14 legacy colours all still offered, NameOf answers,
and the old list is gone from the handler. 433/433 green, 0 warnings.

HANDOFF.md

@@ -34,6 +34,12 @@
   (the old single button showed the *next* action, "Round"). The mutual exclusion lives
   in the model (`IsRectShape`/`IsRoundShape` on `SceneElement`) — a WPF `RadioButton`
   group would kill the bindings. Guard: `ytLive.Tests/PropertiesHierarchyTests.cs`.
+- **TASK 60 — the border-colour drop-down names every colour** (shipped 2026-10-21). The creator:
+  *"the #hex values are good, but add a corresponding color name/label next to the value"* — each row
+  now reads `#e94560  Crimson` (the name dimmed, the tooltip "Crimson (#e94560)"). The 14 colours
+  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`.
 - **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
@@ -169,10 +175,6 @@ Zombie entities deleted from the registry: `script.leak_strobe`, `script.doorbel
    the full top area and the circle option is not offered. **PASSES.**
 
 ## Next step
-- **The creator's remaining ask (not started):** the webcam **Border Color** drop-down should show the
-  **colour NAME next to the hex** (e.g. `#e94560  Crimson`) — the hex stays, the name is the addition.
-  Plan: a testable hex→name catalogue (Models/Helpers) consumed by the code-behind
-  `WebcamBorderColorPicker_Click` in `Controls/LeftPanel.xaml.cs`; the tooltip becomes "Name (#hex)".
 - **Creator check (needs the creator's hands)** — the last piece of the vv feature: switch the
   resolution dropdown to "Vertical 1080p60", confirm the Live camera tile lands inside the band and
   the **Circle** option (TASK 59 turned the Shape button into a Rect | Circle choice) turns the tile
@@ -183,6 +185,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 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
+  (`#16213e`). A 1px `BorderBrush="#2a3a5e"` on the swatch would fix it.
 - **GOG Galaxy launcher shows "offline" (2026-10-21) — GOG's own overnight outage, NOT Windows.** GOG
   put `www.gog.com` behind a maintenance page (503) and their Fastly services for `auth.gog.com` /
   `api.gog.com` / `remote-config.gog.com` return `500 "Fastly error: unknown domain"`; the page itself
@@ -207,9 +213,9 @@ 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: **432/432 passed, 0 warnings** (2026-10-21, this session — after TASK 59's
-  `PropertiesHierarchyTests`; the run before it was 431/431 after TASK 58's
-  `PropertiesStyleTests`). The one failure seen earlier in the session was
+- 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`,
   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…`,