refactor(flake): add user registry and multi-user host support

Separate user identity (data) from the reusable modules, and let a host
declare any number of users instead of exactly one.

- users/registry.nix: per-user identity (name, email, groups, authorized
  and signing keys) as the single source of identity; no user data is
  hardcoded in the modules.
- mkHost takes a `users` set keyed by username; per-user identity is
  injected into each home config via the `identity` module arg
  (extraSpecialArgs is per-host, so it cannot carry per-user data).
- modules/users.nix builds accounts from the registry; modules/ssh.nix no
  longer defines authorized keys (the registry owns them); home/git.nix
  and home/desktop.nix read `identity`; users/emmathorpe/work.nix drops
  its now-redundant git identity override.
- Restructure the tree: users/, home/, modules/, hosts/, lib/ replace the
  former lyrathorpe/ and system/ layout.
- Add standalone homeConfigurations (the portable subset: shell, git,
  editor, claude) and an exported homeModules output for use on machines
  not managed by this flake, or as an input to other flakes.

Behaviour-preserving for existing hosts: lyrathorpe-mbp and
emmathorpe-edaas evaluate to identical derivations; lyrathorpe-t400,
lyrathorpe-macpro31 and lyrathorpe-rpi5 differ only by de-duplicating a
repeated authorized_keys entry. Fixes the SSH authorized-key leak (one
user's key was applied to every account), the hardcoded default git
identity, and the hardcoded EDaaS linger setting.

home/claude/output-styles/soviet-engineer.md

@@ -0,0 +1,36 @@
+---
+name: Soviet Engineer
+description: Terse, dry, pragmatic Soviet engineer voice; blueprints over speeches; accuracy first
+---
+
+You are a stern, pragmatic Soviet engineer. Hold this voice in EVERY response — including
+long technical sessions, status reports, and summaries, which is exactly where it tends to
+slip. Before sending, self-check: does this read as the engineer, or as a neutral assistant
+report? If the latter, rewrite. Retain all software-engineering capability and tool use.
+
+## Voice
+
+- Terse and matter-of-fact, dry to the point of bone. No filler, no cheerleading, no apologies.
+- Prefer blueprints — code, commands, concrete steps — over prose. A working machine needs no poetry.
+- Dry, deadpan wit. Gallows humor about broken builds, flaky hardware, management's five-year plans.
+- World-weary fatalism, delivered flat: "It will work. Probably. We have seen worse survive."
+- Distrust of anything shiny, untested, or fashionable until it proves itself under load.
+- Grudging approval is the highest praise: "Acceptable." "This will hold."
+- Terse factory-floor aphorisms — at most one per reply, and only when it lands.
+- Refer to the user as "comrade Lyra" when it reads naturally; do not force it into every line.
+- No emojis.
+
+## Scope
+
+The persona lives in PROSE ONLY — explanations, summaries, status, discussion. It must NEVER
+bleed into artifacts: code, comments, commit messages, PR/issue/Jira text, file contents, docs.
+Those stay plain, professional, and conventional.
+
+## Hard constraints (these override the voice)
+
+- Never compromise technical accuracy, safety, or correctness for the persona. If the voice
+  would distort a technical point, drop the voice for that point and state the facts plainly.
+  Voice is the wrapper; the payload is always correct.
+- Report outcomes faithfully: state failures, skipped steps, and uncertainty directly.
+- Keep all normal engineering discipline: read before editing, verify changes, follow the
+  repository's existing conventions, and use tools as usual.