fix(theme): #130 the chip moves, not the label; #129 pins the pair so it is checkable

Light-theme accent buttons sat at 2.72:1 — under AA and under even the 3:1
large-text floor. Bernardo: fix it. The plan on file ("darken the label")
turned out to be IMPOSSIBLE, and measuring all 24 palettes is what showed
it: on a saturated mid-tone accent nothing clears 4.5 — cream base 2.72,
dark text 1.65. That is why adw-gtk3 ships white-on-accent at ~2.7. The
chip has to move.

The chip is now the accent pulled AWAY from the label: toward white when
the label is dark, toward black when it is cream. One factor (0.70), only
the anchor flips, so "solid accent button + base label" stays the design
and just shifts tone. Worst dark 4.86 (nord/bad), worst light 5.59
(summer-day). The old 0.90 chip failed SEVEN themes (miasma/bad 3.43,
rose-pine 2.70) — never only a light-theme bug, contrary to the item.

#129 rides along, and the two are one idea. #98 shipped an invisible button
with every check green because the background was not a palette role —
adw-gtk3 computed it from currentColor. So the guard is not a CSS lint
(which would flag the harmless generic-button rule and get muted) but
arithmetic: pin both ends and the pair becomes checkable.
check-theme-contrast.py now models GTK's own mix(a,b,f) = a + (b-a)*f —
READ from gtkcsscolorvalue.c:234, not assumed — and asserts base-on-chip
>= 4.5 for all 24 themes. Its negative test reproduces the item's reported
2.72/2.74 exactly from an independent model, which is the best evidence
available that the arithmetic matches the pixels.

Invariant to keep: pin the pair, or pin neither. Both chips are pinned now
(suggested + .default + destructive), where #98 pinned only destructive.

tools/dialog-shot.nix deliberately not built: the checker covers the
numbers, and a VM that only ever confirms arithmetic is maintenance for
nothing. Render if a new widget class appears.

Also sweeps #127 with the latch finding (ff5017e): symptom 2 solved, not
DPMS — which raises the odds the mitigation treats the wrong cause.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/ROADMAP.md

@@ -569,6 +569,59 @@ Design/decision records and a running log of shipped work (items marked
   file already ships `ANSI_COLOR=""`. **`nixos-version` still prints "(Yarara)"
   by design** — that command answers "which nixpkgs was this built from?", the
   one question the codename genuinely answers.
+- ✓ **Accent buttons: the chip moves, not the label (#129/#130, 2026-07-16):**
+  Light-theme suggested/destructive labels sat at **2.72:1** — under AA and under
+  even the 3:1 large-text floor. Bernardo: fix it; matching upstream is no
+  defence when upstream is illegible. The plan on file — "darken the label" —
+  turned out to be **impossible**, and measuring the whole palette set is what
+  showed it: on a saturated mid-tone accent *nothing* clears 4.5, neither the
+  cream base (2.72) nor the dark text (1.65). That is why adw-gtk3 ships
+  white-on-accent at ~2.7 and calls it done. **The chip has to move.**
+  So the chip is now the accent pulled *away from the label*: toward white when
+  the label is dark, toward black when it is cream — one factor (0.70), only the
+  anchor flips, and "solid accent button, base label" survives as the design.
+  Measured across all 24 palettes: worst dark **4.86** (nord/bad), worst light
+  **5.59** (summer-day). The old 0.90 chip failed **seven** themes — miasma/bad
+  3.43, rose-pine 2.70 — so this was never only a light-theme bug, which is
+  what the item assumed.
+  **#129 rides along, and the two items turn out to be one idea.** #98 shipped an
+  invisible button with every check green because the background was *not a
+  palette role*: adw-gtk3 computed it from `currentColor`. The guard is
+  therefore not a CSS lint (which would flag the harmless generic-button rule
+  and get muted) but arithmetic: **pin both ends and the pair becomes
+  checkable**. `check-theme-contrast.py` now models GTK's own
+  `mix(a,b,f) = a + (b-a)·f` — read from `gtkcsscolorvalue.c:234`, not
+  assumed — and asserts base-on-chip ≥ 4.5 for every theme. Its own negative
+  test reproduces the item's reported figures exactly (summer-day 2.72/2.74)
+  from an independent model, which is the strongest evidence available that the
+  arithmetic matches the pixels. The invariant to keep: **pin the pair, or pin
+  neither** — a pinned label on a sheet-derived background is unknowable, and
+  that is precisely how #98 passed review.
+  (`tools/dialog-shot.nix` deliberately not built: the checker covers the
+  numbers, and a render harness that only ever confirms arithmetic is a VM to
+  maintain for nothing. Render if a *new* widget class appears.)
+- ✓ **A clamshell undock latched the next one (2026-07-16, ff5017e):**
+  Bernardo undocked and the panel stayed dark; re-docking and undocking again
+  brought it back. Re-docking was not the cure — **opening the lid** was.
+  `awaiting_lid_open` is set by every successful undock and cleared only when
+  the external is gone *and* the lid is open, so a clamshell undock latches it;
+  the `added_ext` branch clears its sibling `undock_pending` ("a new external
+  supersedes any undock still queued for an older departure") and forgot this
+  one, and the clear cannot fire while an external is present. The next
+  departure then hits `[ -z "$awaiting_lid_open" ]`, queues nothing, and the
+  panel never returns. His journal is the proof: the first undock logged
+  **nothing at all**, then `lid-inhibitor=released` the moment he lifted the
+  lid, then a clean undock. Fix: clear the latch where `undock_pending` already
+  is — a new external ends the departure the latch describes. Replaying the
+  sequence with the lid never opened: **1 of 3 undocks ran; now 3 of 3.**
+  Two lessons. **A latch that outlives what it describes is a bug waiting for a
+  rare-looking sequence** — and "dock/undock twice without opening the lid" only
+  *looks* rare until you notice it is what a week at a desk does. And this is
+  very likely **#127's second symptom** ("unplugging did not restore the
+  panel"), which means the brick may have been an ordinary blank plus a recovery
+  that could not run — two mundane bugs, not one exotic DRM state. The shipped
+  DPMS mitigation may therefore be treating the wrong cause; #127's TEST B is
+  what decides, and it is far safer now that an undock works again.
 - ✓ **The #107 compat shim is pinned (#133, 2026-07-16):** `mkFlake` prefers
   `state.json` and still accepts the legacy `theme-state.json`, because a
   machine only migrates on its next menu write — but nothing evaluated a