feat(menu): one fingerprint switch, an auto-login toggle, and the state bridge they needed

Bernardo, post-reboot: "Use for login" was the wrong question. Whether the
finger works is one decision, not two, and whether login prompts at all is
a different decision that was never in the menu.

System › Fingerprint is now a single Fingerprint (on/off) switch, leading
the menu with enroll/list/verify/delete as the plumbing behind it. It
writes the one settings.fingerprint.pam key, and modules/home/idle.nix now
defaults idle.fingerprint from that same key — so the lock screen and
login/sudo move together instead of drifting apart the way they did until
e2de906. nomarchy-fingerprint does the two rebuilds this needs (sudo
system for PAM, home switch for hyprlock) and refuses to turn on with no
finger enrolled.

System › Auto-login is new (nomarchy-autologin), and it is what decides
whether anything is asked at boot: auto-login on means no prompt whatever
the fingerprint switch says; off means the greeter asks, for a password or
a finger. Installer-seeded ON for LUKS machines — the passphrase already
gates the disk — and off without it, where the greeter is the only thing
between power-on and the desktop.

Both had to become state-owned to be toggleable at all, which surfaced two
real bugs:

  * nomarchy.system.greeter.autoLogin defaulted from
    `config.nomarchy.settings…` — an attribute that exists ONLY on the Home
    Manager side. On NixOS it is absent and `or null` swallowed the error,
    so the default silently evaluated to null on every machine ever built.
    That is why the installer baked a Nix line: the state path never
    worked. Now read via theme-state-read.nix (the hardware.nix/timezone.nix
    pattern) and mkDefault'd, so the menu owns it and a hand-set line still
    pins it. Two more options read the same phantom bridge — BACKLOG #116.
  * `theme-sync get` printed Python's "None" for a JSON null, so every
    `case … null)` a caller writes would miss. Now prints "null", as the
    comment above it already promised for booleans.

The installer seeds the state instead of emitting the system.nix line,
because that line outranks the state and would strand the toggle.

V1 (V3 pending: HARDWARE-QUEUE). nix flake check --no-build, installer-
safety and option-docs all pass. Proved by eval/build, not assumed: a state
carrying autoLogin yields greetd initial_session {"user":"bernardo"}, the
template state (no autoLogin) yields none, and a hand-set null beats a state
that says otherwise; a state with only fingerprint.pam=true — nothing set by
hand — renders the hyprlock auth.fingerprint block; both new tools pass
bash -n and land in systemPackages (nomarchy-fingerprint only with a
reader); the patcher writes settings.greeter.autoLogin and no system.nix
line; and the get round trip prints null, so the menu reads "Auto-login
(off)" where it would have read "(on)".

The reader itself, the two rebuilds, and the reboot are hardware — queued.

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

docs/HARDWARE.md

@@ -173,9 +173,18 @@ nomarchy.hardware.fingerprint.enable = true;  # services.fprintd
 ### Enroll (menu or CLI)
 
 **Shipped #55:** System › Fingerprint (self-gated when `fprintd-list` is
-on PATH) — Enroll / List / Verify / Delete all, plus **Use for login**
-which writes `settings.fingerprint.pam` and applies on the next
-`sys-rebuild` (option default follows theme-state.json).
+on PATH) — a single **Fingerprint (on/off)** switch, plus Enroll / List /
+Verify / Delete all (all usable while it's off — turning it on needs an
+enrolled finger). The switch writes `settings.fingerprint.pam`, the one
+state key behind *both* halves of "use my finger": login/sudo PAM here,
+and the lock-screen unlock in `modules/home/idle.nix`. It runs
+`nomarchy-fingerprint`, which sudos a system rebuild and then a home
+switch, because the two halves live in different configurations.
+
+It does **not** decide whether login prompts at all: auto-login skips the
+greeter entirely, so this adds the finger to the prompts that actually
+happen — sudo, the lock screen, and the greeter only when
+[auto-login](#auto-login) is off.
 
 **Hints (#73):** MOTD line when `fingerprint.enable` is on; first-boot
 tip when `fprintd-list` is on PATH (`SUPER+M → System › Fingerprint` /
@@ -185,12 +194,34 @@ tip when `fprintd-list` is on PATH (`SUPER+M → System › Fingerprint` /
 # CLI still works:
 fprintd-enroll
 fprintd-list "$USER"
-# or: System › Fingerprint › Use for login (on) → sys-rebuild
+nomarchy-fingerprint toggle     # or on | off | status — what the menu row runs
 ```
 
 PAM stays opt-in on purpose: password-only remains the cautious default
 until a finger is enrolled. Full enroll on a real reader is V3/hardware.
 
+### Auto-login
+
+`settings.greeter.autoLogin` (System › Auto-login, or `nomarchy-autologin
+[toggle|on|off|status]`) decides whether boot goes straight to the desktop
+or stops at the greeter. The installer seeds it ON for LUKS-encrypted
+machines — the disk passphrase already gates the machine, so a greeter
+password is a second prompt for the same thing — and leaves it off
+without LUKS, where the greeter is the only thing between power-on and the
+desktop. It's baked into greetd at system rebuild, so the change shows on
+the next boot.
+
+Auto-login and fingerprint are independent, and auto-login wins at boot:
+with it on you are never asked for anything at startup, whatever the
+fingerprint switch says. Turn auto-login off and the greeter asks — for a
+password, or a password *or* finger when fingerprint is on.
+
+Both are in-flake state rather than lines in `system.nix` on purpose: a
+hand-set `nomarchy.system.greeter.autoLogin` (or
+`nomarchy.hardware.fingerprint.pam`) outranks the state and pins the
+setting, leaving the menu toggle unable to move it. That's the escape
+hatch, not the default — leave those lines commented to use the menu.
+
 ### Parallel prompt (password *or* finger, whichever first)
 
 With `fingerprint.pam` on, sudo/login/hyprlock show **one** prompt that