Add resource-scoped bearer access metadata

docs/architecture.md

@@ -140,8 +140,10 @@ for CLI/control output, but it is not the signed representation.
 The payload access plane is `geth-secrets`: resource master secrets, epochs,
 key envelopes, bearer secrets, and rotation. Revocation for private data is
 modeled initially as secret epoch rotation. The daemon persists resource secret
-epoch metadata through `secret create/rotate/status`, but it does not yet store
-payload key material, encrypt resource data, or distribute key envelopes.
+epoch metadata through `secret create/rotate/status`. Bearer access is recorded
+as resource-scoped auth operations and rejects trust-mutation capabilities such
+as `auth.delegate`, `auth.revoke`, and `node.enroll`. The daemon does not yet
+store payload key material, encrypt resource data, or distribute key envelopes.
 
 ## Multi-User Direction
 

docs/roadmap.md

@@ -181,9 +181,11 @@ resource-scoped capability decisions.
   - `[x]` `geth secret rotate <resource>` records the next resource secret
     epoch.
   - `[x]` Secret epoch rotation is represented in durable metadata.
-  - `[ ]` Bearer secrets grant only resource-scoped capabilities.
-  - `[ ]` Bearer principals cannot mutate trust graph state by default.
-  - `[ ]` Tests verify bearer access does not imply node identity.
+  - `[x]` Bearer secrets grant only resource-scoped capabilities.
+  - `[x]` Bearer principals cannot mutate trust graph state by default.
+  - `[x]` Tests verify bearer access does not imply node identity.
+  - `[ ]` Future completion requires bearer challenge-response proof instead
+    of metadata-only local records.
 
 - `[~]` SSH certificate and revocation lifecycle.
   Acceptance criteria: