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>

agent/BACKLOG.md

@@ -79,6 +79,21 @@ and never re-enables a disabled internal.
   trigger, we are paying a permanent behaviour cost (docked externals never
   sleep) and the brick is still live — so confirming the cause outranks
   #135/#136.
+- **Symptom 2 is SOLVED, and it was not DPMS (ff5017e, 2026-07-16).** Bernardo
+  reproduced "unplugging did not turn the laptop panel back on" live, minutes
+  after TEST A — with **no blanking involved at all** (the mitigation had kept
+  the external lit). Cause: `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; a re-dock clears its sibling
+  `undock_pending` but not the latch, and the next departure is then silently
+  dropped by the `[ -z "$awaiting_lid_open" ]` guard. His journal shows the
+  first undock logging *nothing*, a release the instant he lifted the lid, then
+  a clean undock. Replaying the sequence with the lid never opened: 1 of 3
+  undocks ran; fixed, 3 of 3. **What this does to the theory:** the original
+  brick may simply have been an ordinary blank plus a recovery that could not
+  run — two mundane bugs, not one exotic DRM state. TEST B is now the only
+  thing standing between that hypothesis and the truth, and it is a much safer
+  test with the latch fixed (an undock is a real escape hatch again).
 
 **Pass (current mitigation):** clamshell-docked on AC, idle past 10+ min →
 external stays lit under hyprlock (journal: `dpms-off skipped: clamshell`);
@@ -173,37 +188,6 @@ the key in the same commit.
 trigger, the mitigation is reverted wholesale and this key never exists —
 building it first risks shipping an option for a policy we withdraw.
 
-### 129. Permanent guard for the GTK button-colour trap (#98 follow-up)
-
-The #98 regression (destructive-action at 1.03:1, invisible) was caught only
-by rendering a dialog — every scripted check was green, because the bug lives
-in adw-gtk3's `mix(@destructive_color, alpha(currentColor,…))` background, not
-in our CSS. `tools/theme-shot.nix` is deliberately not a CI gate (full-desktop
-VM), so add the cheap static half: assert that for every theme, any rule that
-pins a button label colour also pins that button's `background-color` — i.e.
-no pinned label may sit on a `currentColor`-derived background. Guards the
-class, not the instance. The scratch render harness that found it is worth
-promoting to `tools/dialog-shot.nix` as a maintainer tool alongside theme-shot.
-
-### 130. GTK accent buttons sit at ~2.7:1 in light themes
-
-Fallout noted while fixing #98: in light palettes the suggested/destructive
-labels are base00 (cream) on saturated accent/bad — summer-day measures
-**2.72:1** (suggested) and **2.74:1** (destructive), under AA 4.5 and even
-under the 3:1 large-text floor. Not a regression: upstream adw-gtk3 does the
-same (`color: white` on the accent), so we currently match GNOME.
-
-**Decided 2026-07-16 (Bernardo): fix the contrast — we hold ourselves higher
-than GNOME here.** Matching upstream is not a defence when upstream is under
-even the large-text floor; "everyone ships it" is how 2.7:1 text becomes
-normal. Two shapes to pick between while building: darken the *label* (the
-label is ours; the accent is the user's palette and the thing they chose the
-theme for), or darken the *accent mix* under the label in light palettes only.
-Prefer the first unless it looks wrong — it leaves the palette alone.
-Note `tools/check-theme-contrast.py` covers palette pairings only, never GTK
-widget surfaces, so whatever lands needs its own assertion or it rots exactly
-like #98 did.
-
 ### 143. Rofi keeps the selected *row number* when the search changes, so the highlight lands on an unrelated entry
 
 Bernardo 2026-07-16, and his repro is exact: open the app menu, type `ca`, move