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/JOURNAL.md

@@ -19,6 +19,35 @@ Template:
 
 ---
 
+## 2026-07-16 — #137 + #145: the splash follows the canvas, and says your layout
+- **Task:** #137 (splash off-centre docked) + #145 (keyboard layout on the LUKS
+  prompt, with Fedora's icon).
+- **Did:** one `layout()`, re-run from the existing refresh callback on canvas
+  change; `@LAYOUT@` + `@FG_*@` baked by plymouth.nix like the palette already
+  is; plymouth's own `keyboard.png` copied at build time and recoloured.
+- **The lesson, and it is the whole entry:** I was wrong twice, and only the
+  render rig caught it. Not head-0 geometry (`Window.GetWidth()` = `max_width`);
+  not per-head sprites (would have duplicated the logo — the plugin already
+  centres each display in the canvas). The bug was **time**: positions computed
+  once at parse time vs a canvas that resizes when a head arrives. And attempt 1
+  of the fix died on a plymouth-script trap: **a bare assignment inside a
+  function writes the global if that name exists globally**, so
+  `canvas_width = Window.GetWidth()` updated the very global its guard compared
+  against — always false, nothing drawn, **no error logged**. Isolated with a
+  20-line probe (`[after assign: global.canvas_width=800][guard SKIPPED]`).
+  Both facts are now comments in the script; do not re-derive them.
+- **Verified:** V0 + V2 by render — `tools/plymouth-preview.sh` with the real
+  built theme: both heads centred, and the password dialog showing padlock,
+  entry, and ⌨ + `us`. Also caught, only because I read the build log: copying a
+  file from the store keeps it **444**, so `recolor` failed, the phase aborted,
+  and **every later sed silently did not run** — the theme shipped with `@BG_R@`
+  literals. `chmod +w`. Check build logs, not just exit codes.
+- **Pending:** V3 queued — a real docked boot/shutdown is the only way to resize
+  a canvas (the rig's fake heads exist from the start). Recovery if the splash
+  is ever blank: the prompt is invisible but live (type blind), or boot the
+  previous generation.
+- **Next suggestion:** #129/#130 (GTK contrast) or #133 (the #107 shim check).
+
 ## 2026-07-16 — "fix the rest": #140, #142, #144 shipped; #137 re-diagnosed
 - **Task:** the T14s round's remainder. Bernardo picked configurable-provider +
   drop-the-CLI for #140 (and asked for chatgpt/grok in the list).