#3165 Docs: vault grants and run vault scoping on swamp serve (swamp-club#2676, swamp-club#2206)

swamp-club/swamp#2915 adds a vault: grant resource kind and holds every vault operation in a serve run to the triggering principal's vault grants. The swamp repo's design/enablers/access-control.md (section Vaults) and the swamp skill serve guide (Vault Access) carry the full rules; the manual needs to teach them.

Stale text to fix:

• content/manual/reference/swamp-serve/authorization.md, 'Not yet covered' (~line 355): drop the Vaults (swamp-club#2676) bullet.
• Same page, 'Vault secrets' (~433-450): it says a vault.get expression is an author capability never checked against grants. That now holds only while the policy has no vault grant; replace with the run-time rule.
• Same page, actions table (~85): read covers vaults; add the vault kind to the resource kinds.

Reference (authorization.md, plus access-commands.md):

• vault: resource kind, patterns (exact or trailing *), condition fields name and key.
• Request rule: a deny on data:vault, data: or vault: refuses; today's check or a vault: allow admits. Behaviour change: a data: deny on a vault name now refuses every request for that vault; migrate vault denies to vault:. Refresh options on vault put still need admin on data:vault.
• Run-time rule: reserved vaults (_token-secrets) refused to every serve run except admin on access:*; inert until the policy holds a vault grant; a vault deny refuses; any vault allow makes the principal deny-by-default for vaults on every action; data grants play no part at run time.
• Resumes are scoped to the run's recorded triggering principal and memberships, never the approver; server-token runs are cut off when the token is revoked, re-minted or deleted (not on expiry alone); OAuth login tokens are not re-checked; runs with no recorded principal (older releases) are refused once vault grants exist.
• Scheduled and webhook runs share one service principal, so its vault grants apply to all of them; use the workflow vaults list per workflow.
• access can-i / check print an 'In serve runs:' line and a runVaultAccess JSON field.
• Denials are audited (category secrets, outcome denied).

Reference workflows.md: the optional top-level vaults: allow-list (applies to local runs too, intersects through nesting, recorded at run start so an edit can narrow but not widen a suspended run, must include the vault sensitive outputs land in; workflow validate reports missing names; older releases reject a workflow file that sets it).

How-to (manage-access-grants.md or a new 'limit which vaults a run can use'): the bot example (allow read on vault:roomcontrol, refused erp), deny-only example, the outputs-vault guideline (scoped principals need read and write on the vault sensitive outputs land in; keep author secrets out of it), and upgrade every serve replica before writing vault grants (older replicas reject a grants file with vault grants and ignore stored ones, denies included).

Explanation (swamp-serve.md): the shell-step limit. A shell step that runs a nested swamp or a provider CLI reads vaults with the host's own access and is not bounded by grants; isolate such workloads with a separate orchestrator or provider credentials.