Keep these consistent

• One key. The guard set's key (Policy.key) names a principal. Give the same to the resolver (key: Policy.key), so the subject header the client repeats (Me.key, AuthServer.answered) is checked the way it was said.
• Fresh principals, not claims. Build the User per request from the session's subjectId. A claim is a snapshot from sign-in, and a rule over a stale membership is a hole.
• Every host, the same resolver. Remote's serveFetch, a Sync document's socket (documentHost with requests: 'browser', since a browser's WebSocket sends no CSRF header), and SSR's posted forms each resolve the principal the same way, and guard decides each the same way.
• Validate at startup. Call GuardServer.validate(Policy, …) where the server is built, so a Source that forgot its rules fails loudly.

See also#

• foldkit-auth and foldkit-guard, each in full.
• examples/auth: sign-in, Me, guarded notes, a page Site.access sends a visitor away from, and a Sync board, end to end.