docs: take the lockscreen out of casey's uid

The current user unit wins the boot race but still runs as the human whose Personal key the lock is meant to evict. Record the target souveraine-session principal, its narrow Wayland/PAM/data reach, and the fact that the rich shell is presentation—not release authority.

docs/SESSION-TRUST-ARCHITECTURE.md

@@ -8,6 +8,7 @@ must consume rather than replace.
 
 | Question | Authority | Souveraine's role |
 | --- | --- | --- |
+| Who owns the secure pre-unlock surface? | Dedicated `souveraine-session` principal + compositor lock protocol | Sessiond decides and audits; the shell renders; Casey authenticates but does not own the lock process. Target design, not current user-unit state. |
 | Can this machine suspend, hibernate, power off, or reboot? | logind `Can*` methods | Query and expose the answer; execute the matching logind/systemd verb. |
 | Has the compositor secured the display? | `WlSessionLock.secure` | Mirror it as `screenLockSecure`; never infer it from a button press. |
 | Does the shell want its lock surface shown? | `GlobalStates.screenLocked` | Maintain this request state and persist it across a shell crash. |

docs/STORAGE-ENCRYPTION.md

@@ -243,6 +243,14 @@ delivery, decision deferred:
 `Unlock` stops being a no-op once the daemon consults lock state; this closes
 `audit-status.md` P2 as a consequence, not separate work.
 
+The lockscreen must not run as the human whose Personal key it evicts. The
+target is a dedicated `souveraine-session` principal: package code plus
+Ambient and tightly scoped Revealable state, with no access to Casey's home or
+any agent's memory. PAM authenticates Casey; it does not make the lock
+authority Casey or hand it the decrypted Personal tree. The living owner and
+current user-unit gap are recorded in
+`../../souveraine/saf/authority/01-session.md`.
+
 ## Federation — encrypt then push
 
 The Gitea remote is **untrusted by design.** It is trusted in the reference

docs/session-authority-boot-order.md

@@ -20,6 +20,14 @@ unreachable); deploy checklist below. Phases A/B remain skipped, except the
 restore flag and splash timing which Phase C absorbed (sessiond pokes
 splash-signal from its own first frame).
 
+**Ownership correction, 2026-08-17:** the zero-gap handoff below describes the
+current implementation, not the final principal boundary. The rich shell is a
+presentation client; it must not become the authority merely because it draws
+the normal lock face. The target keeps lock policy and release under sessiond
+running as dedicated `souveraine-session`, while Casey is only the PAM subject
+and Personal-key owner. The living design is
+`../../souveraine/saf/authority/01-session.md`.
+
 ## What actually happens at boot today
 
 1. `souveraine-splash` takes DRM master (`Before=greetd.service`) and covers

docs/souveraine-components/sessiond.md

@@ -60,6 +60,13 @@ conversation on sessiond's own lock surface.
 - **Fail-closed default.** Default behavior on start is to lock; `--no-initial-lock`
   is the explicit opt-out for dev.
 
+Sessiond is still packaged as a user unit with no `User=` directive. It
+therefore runs as the human graphical-session owner. That ordering closes the
+boot visibility hole but does not close ownership of the lockscreen. The
+target principal is `souveraine-session`, with only the Wayland lock, PAM,
+Ambient, and Revealable reach described in
+`../../../souveraine/saf/authority/01-session.md`.
+
 ## Audit gaps (toward the RedFlag bar)
 
 sessiond is the component that most directly maps onto RedFlag's "capability