Raise the contrast of the labels, digits and delay readout

F-Droid's reviewer measured the score and move lines at 2.1:1 against the
4.5:1 normal text needs. Raising them past 14pt bold puts them under the 3:1
large-text bar instead, which is the only way ink still readable as "muted"
can be conformant on a mid-tone accent: reaching 4.5:1 at the old size would
have taken near-black labels on plum and slate, out-shouting the clock digits
above them. Hence the 19px floor, with a comment saying so — lowering it
breaks the contrast claim silently.

Measuring turned up a second failure nobody had flagged: the active player's
clock digits are white on the accent, and brass sat at 2.46:1 against the same
3:1 bar. Sage and brass are darkened just far enough to clear it, scaled in
linear light so only lightness moves. Slate, teal and plum already passed and
are untouched. Darkening further was tempting and wrong — it would have taken
the headroom the muted labels need.

--accent-mute was doing double duty as the delay bar's background, where it
only ever agreed with the bar by accident. Splitting off --track keeps the bar
pixel-identical: 234px wide, fill and unfilled segments unchanged.

The delay number is right-aligned in a box exactly two digits wide. The bar and
the number together now sit within a pixel of the panel's centre rather than
10px left of it, and the digit that changes every second stays put instead of
sliding when the count drops out of double figures; the gap absorbs it.

The settings sheet's Done button and preset chips are still white on accent at
15px, which needs 4.5:1 and gets 3.2:1. Known, and left alone: fixing them
means 19px floors and visibly taller buttons.

Screenshots come from tools/screenshots.py now instead of being made by hand.
It seeds localStorage and lets the app render its own saved state, so scenes
are reproducible. The traps are in its docstring and RELEASING.md — including
one that cost an afternoon today: snap-confined Chromium cannot write into any
hidden directory, and says only "Permission denied".

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

RELEASING.md

@@ -110,10 +110,22 @@ Separate from all of the above, and manual: upload the six files in
 
 ## If the screenshots need redoing
 
-`fastlane/metadata/android/en-US/images/phoneScreenshots/` holds five shots at
-1170×2532. They are generated from `public_html/index.html` itself with headless
-Chromium, not taken on a phone, so they can be regenerated exactly. Two traps if
-you do it by hand:
+```bash
+python3 tools/screenshots.py
+```
+
+That rewrites all five in
+`fastlane/metadata/android/en-US/images/phoneScreenshots/` at 1170×2532. They
+are rendered from `public_html/index.html` with headless Chromium, not taken on
+a phone, so they reproduce exactly — anything that changes the look of the app
+is a reason to re-run it.
+
+The script sets each scene by seeding `localStorage` before the app boots, so
+the app renders its own saved state rather than having the DOM poked from
+outside. Editing a scene means editing the `SCENES` table at the top.
+
+Three traps, all of which fail quietly, and all of which the script already
+handles — they are written down here because they cost an afternoon each:
 
 - The capture lands whenever the virtual-time budget runs out, not when your
   script finishes — so freeze the render loop (`requestAnimationFrame = () => 0`)
@@ -121,6 +133,10 @@ you do it by hand:
 - CSS transitions don't advance under `--virtual-time-budget`, so a panel caught
   mid-transition photographs in its *old* colour. Disable transitions in the
   screenshot build.
+- Snap-confined Chromium cannot write into hidden directories — not `~/.cache`,
+  not any dot-directory, not the private `/tmp` it is handed. It fails with a
+  bare "Permission denied" and no hint as to why. Both the HTML it reads and the
+  PNG it writes have to sit in a plainly-named directory.
 
 ## Reference