fix(swaync): palette-safe pairings — text was invisible on summer-day (item 25)

Palette roles aren't uniform: summer-day and flexoki-light use subtext
as text-ON-surface (== base) and surface as a dark chip (== text), so
swaync's @subtext-on-@base body text and @surface/@text buttons were
self-colored (caught on the Latitude).

- body/summary: @text on @base — the one text pairing that passes in
  every palette (survey: worst WCAG ratio 5.18 across all 21 themes;
  subtext/base bottomed at 1.00 twice, muted/base at 1.27).
- hover rows + widget-title buttons: alpha(@text, 0.1) tints —
  contrast by construction; subtext/surface defines dropped.
- NEW checks.theme-contrast (tools/check-theme-contrast.py): asserts
  the hex-on-hex text pairings across themes/*.json, cheap (no VM).

The audit also found the generated waybar/rofi CSS shares the bug
class, live on flexoki-light (no whole-swap) → BACKLOG item 27.

Verified: V0; V1 (checks.theme-contrast builds green, 21 themes;
rendered services.swaync.style has zero @subtext/@surface). Honesty:
NOT visually verified — V3 queued (notify-send on summer-day).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

agent/BACKLOG.md

@@ -22,26 +22,28 @@ next, in what order*.
 
 ## NOW
 
-*Items 21–26: real-hardware QA findings from the Latitude 5410
+*Items 21–27: real-hardware QA findings from the Latitude 5410
 (Bernardo, 2026-07-04) — bugs found on metal outrank the queue.*
 
-### 25. swaync text unreadable on summer-day (light-theme contrast)
-Reported: on summer-day, notification/control-centre text is invisible
-(contrast). Root cause (traced 2026-07-04): swaync.nix renders `.body`
-as `@subtext` on `alpha(@base, 0.95)` — but in summer-day (and
-flexoki-light) `subtext` *equals/≈ base* because those palettes use
-`surface` as a dark contrast surface and `subtext` as text-*on*-surface,
-not "dimmer text" (catppuccin-latte-style). summer-day also has
-`surface == text` (#5c6a72), so `.widget-title > button`
-(@surface bg, @text fg) is self-colored too. Fix direction: swaync.nix
-should pair roles that contrast by construction — `muted` (dim-text
-role in every palette) for body text on @base, and button fg that
-contrasts @surface (`subtext` is arguably the *right* role there) —
-or normalize the palette semantics across the light themes; audit the
-other `@subtext`/`@surface` consumers (waybar css, rofi) for the same
-mispairing before choosing. **Verify:** V1 + a contrast assert over all
-themes (text≠bg for each swaync pairing); V2 themed-VM screenshot with
-a `notify-send`; V3 re-check on the Latitude.
+### 27. Generated waybar/rofi CSS invisible on on-surface palettes
+Found by item 25's audit: the generated Waybar CSS colors `#window` and
+the whole module row `@subtext`, and the generated rofi theme puts `@fg`
+text on `@surface` backgrounds (inputbar, textbox, `element alternate`).
+In palettes where subtext/surface mean "on-surface" (flexoki-light:
+subtext==base AND surface==text) those are invisible. summer-day/night
+escape via their whole-swap waybar.css/rofi.rasi — **flexoki-light does
+not** and runs the generated CSS. Same class of fix as the shipped
+swaync one (63136a8-follow-on): move the generated surfaces to pairings
+that contrast by construction (alpha(@text) tints; @text for module
+text with per-module accents kept), then extend
+tools/check-theme-contrast.py's PAIRINGS to cover waybar/rofi so
+`checks.theme-contrast` guards them too. Waybar changes must respect
+the parity rule (generated bar only — the summer whole-swaps are
+hand-authored and unaffected). Alternative worth weighing in-iteration:
+normalize the flexoki-light palette itself (make subtext dim-text,
+surface elevated-bg) — smaller diff but changes the theme's look
+everywhere. **Verify:** V1 + the extended contrast check across all 21
+themes; V2 themed-VM screenshot on flexoki-light if cheap; V3 eyeball.
 
 ### 22. Network menu shows nameless/weird entries
 Reported: `networkmanager_dmenu` lists entries with no names (likely