[Security] Document and mitigate 60s permission-cache stale windows #424

Summary

Permission caching intentionally allows up to 60s staleness, which is a pragmatic tradeoff but not strict zero-trust immediacy.

Why this is nuanced

This is not necessarily a bug, but it is a security-model caveat that should be explicit and mitigated for sensitive operations.

Current behavior (evidence)

• 60s permission cache TTL in packages/lib/src/permissions/permissions-cached.ts.
• Logs acknowledge stale-permission windows when invalidation fails.

Risk / impact

Temporary over-permission or delayed revocation visibility for read paths relying on cached results.

Proposed remediation

• Document stale-window behavior in threat model and operator docs.
• Ensure sensitive mutations and high-risk actions bypass cache.
• Improve invalidation reliability and observability.
• Consider shorter TTL or event-driven cache busting where feasible.

Acceptance criteria

• Security docs explicitly state revocation propagation guarantees.
• Sensitive endpoints demonstrate bypass-cache or equivalent fresh auth checks.
• Monitoring/alerts cover cache invalidation failures and stale-permission incidents.