docs: reconcile sessiond plan with existing authority doctrine and services family

docs/session-authority-boot-order.md

@@ -77,11 +77,25 @@ Small, current architecture, closes the observed boot hole.
 
 ## Phase C — the authority below the shell (`souveraine-sessiond`)
 
-The doctrine's end-state: the lock authority is not a QML panel inside the
-thing it guards. Shape:
+Not greenfield. This is the session-authority face of the unified authority
+doctrine §11 already names — capability tiers, capability gate (RedFlag's
+attested-binary / capability-token pattern pointed inward, §10), seed identity
+as signer, memfs as audit trail. The souveraine services family this daemon
+joins **already exists**: `souveraine-machined` owns the machine Ed25519 seed
+and serves pubkey/sign over `/run/souveraine/machined.sock` (clients get
+signatures, never key material); `souveraine-secrets` backs
+`org.freedesktop.secrets` from the same seed lineage. sessiond is the next
+binary in that family, and per §11 the session authority and the binary
+authority are the same authority — sessiond verifies capability tokens on the
+things that ask it to unlock/inhibit/step-up, and its own binary carries the
+same attestation it checks (RedFlag constraint #5 applies: policy before
+kernel stops; eBPF raises bypass cost later).
 
-- A small Rust daemon in the substrate (peer of `souveraine-secrets`),
-  systemd user unit ordered before the shell.
+Shape:
+
+- A small Rust daemon in the substrate (peer of `souveraine-machined` /
+  `souveraine-secrets`), systemd user unit ordered before the shell. Signing
+  needs go through machined's socket like every other service.
 - **At session start it takes ext-session-lock immediately** — the lock
   exists before the shell process does. The splash becomes purely aesthetic.
 - It renders a **minimal** lock surface (spartan PIN entry) and owns the PAM
@@ -97,7 +111,13 @@ thing it guards. Shape:
 - sessiond is then the natural home for the rest of the authority surface:
   the lock IPC endpoint (`blueline-power-button` talks to it instead of `qs
   ipc`), the PrepareForSleep lock race (doctrine §8), the `souveraine-stepup`
-  PAM service, and eventually the portal Inhibit backend (§6).
+  PAM service, capability-token verification for session verbs (§10), and
+  eventually the portal Inhibit backend (§6).
+- This lands inside the services-infrastructure review the security audit
+  register already queued (SECURITY-AUDIT.md "Next thread"): session
+  authority, secrets, federation transport, sensor service, machined —
+  reviewed as one composition, not five builds. sessiond's design belongs to
+  that review, not to a standalone lockscreen fix.
 
 Open question, deliberately not answered here: does the rich lockscreen
 eventually move *into* sessiond (lock surface never depends on shell health,
@@ -110,13 +130,10 @@ gap or heartbeat proves flaky in practice.
 
 1. Phase A default-closed mechanism: env var in the phone launch line vs
    lock-at-start everywhere (laptop dev-loop pays a lock-flash per restart).
-2. Whether "souveraine user" means anything beyond sessiond — a literal
-   second UID owning the session was considered and looks wrong (Wayland
-   clients across UIDs on one compositor: socket perms, portals, pipewire,
-   dbus all split-brain). Needs Casey's confirmation of intent.
-3. Phase ordering vs the rest of the queue (favorites, lockscreen
+2. Phase ordering vs the rest of the queue (favorites, lockscreen
    recreation). Note lockscreen recreation and Phase C interact: where the
-   rich surface lives decides where that work lands.
+   rich surface lives decides where that work lands — and Phase C itself
+   belongs to the services-infrastructure review.
 
 ## Verification owed when implemented