docs(agent): reconstruct the five journal entries a crashed session owed

A session crashed after shipping the fingerprint/idle/menu batch. The work
itself survived intact: 625b7e3, e2de906, fbbeac6, 9792976 and eb38008 are
committed and pushed, and each did its own sync sweep — BACKLOG #115/#116
filed, HARDWARE-QUEUE carrying the toggle test and the removed fprintd trap,
docs and template updated. Only the journal was owed, so the next session
would have read docking round 7 as the head and missed five iterations of
context, including two live bugs the batch exposed.

Reconstructed from the commit messages rather than from memory, and marked
as such in the file — the commits are the record, this is an index into
them. The entries keep what the messages proved and what they left pending,
notably the lesson from fbbeac6 (the lock field has never been visible; I
assumed it was and reasoned from there) and the one from 625b7e3 (a check
that passes whether or not the property holds is worse than no check).

V0: nix flake check --no-build passes. Docs-only.

Noted, not done: the journal is at 56 entries against its own ~25 rotation
threshold — it was already 51 before this, so the tail is overdue for
JOURNAL-ARCHIVE.md. That is its own commit, not this one's business.

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

agent/JOURNAL.md

@@ -19,6 +19,113 @@ Template:
 
 ---
 
+> The five entries below were reconstructed from the commits on 2026-07-14
+> after a session crash — the work was committed and pushed, and each commit
+> did its own sync sweep (BACKLOG #115/#116, HARDWARE-QUEUE, docs); only the
+> journal was missing. Written from the commit messages, not from memory.
+
+## 2026-07-14 — one fingerprint switch, an auto-login toggle, the state bridge (eb38008)
+- **Task:** Bernardo, post-reboot: "Use for login" was the wrong question —
+  whether the finger works is one decision, and whether login prompts at all
+  is a different one that was never in the menu.
+- **Did:** System › Fingerprint is now a single on/off switch (enroll/list/
+  verify/delete demoted to plumbing behind it) writing the one
+  `settings.fingerprint.pam` key; `idle.nix` defaults `idle.fingerprint` from
+  that same key, so lock screen and login/sudo move together. New System ›
+  Auto-login (`nomarchy-autologin`), installer-seeded ON for LUKS machines.
+  Making both state-owned surfaced two real bugs: `greeter.autoLogin`
+  defaulted from `config.nomarchy.settings…`, an attribute that exists ONLY
+  on the HM side, and `or null` swallowed it — the state path never worked on
+  any machine ever built; and `theme-sync get` printed Python's `None` for a
+  JSON null, so any `case … null)` would miss.
+- **Verified:** **V1** — flake check, installer-safety, option-docs pass.
+  Proved by eval/build: a state carrying autoLogin yields greetd
+  `initial_session`, template state yields none, a hand-set null beats the
+  state; `fingerprint.pam=true` alone renders hyprlock's auth block; both
+  tools bash -n clean and land in systemPackages; the get round trip prints
+  `null`.
+- **Pending:** V3 — HARDWARE-QUEUE "fingerprint + auto-login toggles on
+  hardware" (T14s, after unpinning the two system.nix lines). Filed **#116**
+  (two more NixOS options read the same phantom bridge — a grep for
+  `config.nomarchy.settings` under `modules/nixos/` should return nothing when
+  done) and **#115** (suspend-then-hibernate, `[human]` on delay/AC policy).
+- **Next suggestion:** #116 — the worked example is in the tree and the two
+  remaining reads are known.
+
+## 2026-07-14 — a real lock bind, and a lock screen that speaks in sentences (9792976)
+- **Task:** two nits from the post-reboot hardware pass.
+- **Did:** Super+Escape never locked anything — there was no lock bind at all,
+  only the power menu's Lock row and the idle timeout. Lock now lives at
+  Super+Ctrl+L (bare Super+L collides with common app binds), dispatching
+  `loginctl lock-session` — the power menu's path, so hypridle's `lock_cmd`
+  stays the single place deciding what a lock looks like. The prompt's clipped
+  fragments are sentences now, placeholder sentence-cased to match.
+- **Verified:** **V1** — flake check; the built home generation carries the
+  bind, the new ready/present messages (built with `idle.fingerprint` forced
+  on, since the in-repo config leaves it off), and a cheatsheet row the
+  generator produced on its own from the shared list.
+- **Pending:** V3 — the reader itself only exists on hardware.
+- **Next suggestion:** the fingerprint/auto-login menu surface (became eb38008).
+
+## 2026-07-14 — put the fingerprint hint where it can be seen (fbbeac6)
+- **Task:** e2de906 fixed the invisible reader and left an invisible message —
+  Bernardo: "unlock worked, but still no message", same symptom as before the
+  fix, completely different cause.
+- **Did:** the lock screen is deliberately clock-only — the input field fades
+  out while empty (hyprlock's `fade_on_empty` default), so `$FPRINTPROMPT` in
+  its placeholder rendered faithfully into a widget nobody sees until they had
+  already given up on the finger and started typing. Moved to a label; the
+  placeholder goes back to its exact previous string, so the non-fingerprint
+  path is unchanged.
+- **The lesson:** I assumed the field was visible and reasoned from there. It
+  has never been visible — "it has always been like this" is what cracked it.
+  Both candidate surfaces (label vs `fade_on_empty=false`) were tested on
+  hardware rather than picked; Bernardo chose the label, which keeps the
+  clock-only look instead of making opting into fingerprint mean permanently
+  gaining a widget the design never had.
+- **Verified:** **V2** — flake check; checks.theme-contrast + option-docs pass
+  (`subtext-on-base` is held to a 3.0 floor on all 21 themes by the guard that
+  exists because two themes once shipped subtext == base — the same bug as
+  this commit, one layer down). **V3** — Bernardo confirms the line reads.
+- **Next suggestion:** the lock bind + prompt copy nits (became 9792976).
+
+## 2026-07-14 — unlock by fingerprint; hyprlock never used the PAM flag (e2de906)
+- **Task:** Bernardo tested the lock screen with `fingerprint.pam` on — sudo
+  took a finger, hyprlock did nothing.
+- **Did:** the PAM stack was never the problem (grosshack sits in
+  `/etc/pam.d/hyprlock` at order 11400 exactly like sudo's) — hyprlock just
+  never asks it: its PAM conversation runs only on submit, so a module wanting
+  to prompt *while* polling the reader never gets a turn. It has its own
+  fprintd-over-D-Bus backend behind `auth:fingerprint:enabled`, which nothing
+  in the distro ever set. New `nomarchy.idle.fingerprint` (default false),
+  mirroring `hardware.fingerprint.pam` the way `keyboard.layout` mirrors the
+  xkb option — hyprlock is configured in standalone HM, which has no
+  `osConfig`. Opt-in, because with no reader hyprlock advertises a scan that
+  cannot happen.
+- **Verified:** **V2** — flake check; checks.option-docs passes (failed first
+  with "undocumented option", the check doing its job).
+- **Pending:** V3 — Bernardo applies and confirms both factors work.
+- **Next suggestion:** confirm the prompt actually renders (it did not —
+  fbbeac6).
+
+## 2026-07-14 — parallel fingerprint: 3 of 4 counts confirmed, 1 removed as a trap (625b7e3)
+- **Task:** HARDWARE-QUEUE "parallel fingerprint-or-password on the real
+  reader" (Bernardo, AMD dev box, gen 422, `fingerprint.pam = true`).
+- **Did:** confirmed on the real reader: one prompt, typed password works,
+  sensor works, wrong-finger ×3 falls back to password. The fourth count —
+  "password keeps working with fprintd stopped" — is **removed rather than
+  checked off**: fprintd is D-Bus activated, so `systemctl stop` does not keep
+  it down. Bernardo ran it and the fingerprint still worked, which is exactly
+  the evidence the daemon came back and the dead-reader path was never
+  exercised. A check that passes whether or not the property holds is worse
+  than no check. The property needs no hardware anyway: password is `auth
+  sufficient` at 11700, independent of the fprintd rule at 11400 — visible by
+  eval, asserted by checks.hardware-toggles in a reader-less VM.
+- **Verified:** V3 (hardware, Bernardo) for the three counts; docs-only commit.
+- **Pending:** still open on that item — hyprlock, the greeter (needs the
+  reboot), and `fingerprint.parallel = false` restoring sequential behavior.
+- **Next suggestion:** the hyprlock half (became e2de906).
+
 ## 2026-07-14 — docking round 7 FAILED; the keyword was inert, not raced (this commit)
 - **Task:** HARDWARE-QUEUE docking round 7 result (Bernardo, AMD dev box) —
   5–6 consecutive unplugs, the panel never came back. Round 6's fix did