fix(plymouth): #137 splash follows the canvas; #145 keyboard hint on the LUKS prompt

The logo was off-centre on the external when booting/shutting down docked.
Both earlier diagnoses in this repo were WRONG, and that is the part worth
keeping: Window.GetWidth() returns max_width (not head 0), and per-head
sprites would have DUPLICATED the logo — the script plugin already builds
one max_width x max_height canvas, centres every display inside it
(script-lib-sprite.c:536) and draws sprites at (sprite.x - display.x), so a
canvas-centred sprite is centred on every head. The arithmetic was right.

The bug was TIME: every position was a top-level statement evaluated once
at parse time. A head arriving/leaving mid-splash resizes the canvas, the
plugin re-centres the displays, and frozen sprites end up off by
(new_max - old_max)/2 on every head. One monitor never resizes the canvas —
hence "only when docked". Fix: one layout(), re-run from the existing
refresh callback on canvas change.

The trap that cost two attempts (now a comment): in plymouth script a bare
assignment inside a function writes the GLOBAL if that name already exists
globally. So `canvas_width = Window.GetWidth()` updated global.canvas_width
BEFORE the guard compared against it — always false, body never ran, splash
rendered as a bare background, NO error logged. Isolated with a 20-line
probe. Hence cw/ch.

#145 rides along: a VT loads one keymap and knows nothing of per-device
layouts, so the passphrase box types with the console layout — worth saying
before three wrong tries on a disk you cannot read (same gap as #114, one
step earlier). Fedora's mechanism does not port: ply_keymap_icon is a C
widget in the two-step plugin (the script plugin has no keyboard API), fed
from XKBLAYOUT in /etc/vconsole.conf, which NixOS never writes (plymouth's
trace says `XKBLAYOUT: (null)`). So @LAYOUT@ is baked from
services.xserver.xkb.layout like the palette — the FIRST of a comma list,
since that is what the VT loads. Icon is plymouth's own keyboard.png (the
same glyph Fedora shows), copied at build time so no GPL bytes enter the
repo, recoloured to subtext.

chmod +w after that copy: store files are 444 and recolor rewrites in
place. Without it magick fails, the phase aborts, and EVERY LATER SED
SILENTLY DOES NOT RUN — the theme shipped with @BG_R@ literals and I only
caught it by reading the build log.

Verified by render (tools/plymouth-preview.sh, real built theme): both
heads centred, password dialog showing padlock + entry + keyboard icon and
"us". V3 queued — only a real docked boot can resize a canvas.

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

agent/HARDWARE-QUEUE.md

@@ -509,6 +509,17 @@ Everything else below stays open; order is convenience, not a gate.
       active and PPD switching governors; opt-ins: ROCm (`rocminfo`, a GPU
       PyTorch/Ollama smoke) and the XDNA NPU driver loading.
 - [ ] **Fingerprint** — `fprintd-enroll` + (opt-in PAM) login/sudo.
+- [ ] **#137/#145 splash on a real docked boot** — the one thing the render rig
+      cannot do: its fake heads exist from the start, so the canvas never
+      resizes, which *is* the bug. **Docked**, reboot: pass = the logo is centred
+      on **both** panels at boot **and** at shutdown (it was off-centre on the
+      external), and the LUKS prompt shows the padlock, the entry, and beneath it
+      a keyboard icon + your layout (`us`). Then reboot **undocked** — unchanged.
+      Rendering is already proven (`tools/plymouth-preview.sh`, both heads +
+      `ask-for-password`), so what is unproven is only a canvas that changes
+      under a real DRM boot. If the splash is ever blank, the passphrase prompt
+      is invisible but still live — type it blind, or pick the previous
+      generation in the boot menu, which carries the old theme.
 - [ ] **#142 dock mode survives a rebuild** — **relogin first** (the watcher is
       `exec-once`; `nomarchy-home` alone leaves the old one running and you
       would be testing nothing — round 6's lesson). Then, docked: run