docs(adr): decide RLS coverage for users / sessions / session_redirects tables

[cmeans-claude-dev]

Decision needed, not code. The RLS fixture's _RLS_TABLES constant covers (entries, reads, actions, embeddings). Other owner-adjacent tables aren't covered:

• users
• sessions
• session_redirects

Question

Are these intentionally global (admin/cross-user auth-layer visibility) or should they have RLS applied like the data tables?

Considerations

• users: OAuth linking, profile, email lookup. Arguably needs cross-user visibility for linking flows and admin tooling — global may be correct.
• sessions: transient session state. If RLS-covered, ensure background session-cleanup paths have a privileged role.
• session_redirects: OAuth redirect state during the auth dance. Probably per-session-short-lived; RLS may or may not matter.

Deliverable

A short ADR (≤1 page) in docs/adrs/ or a section in docs/security.md stating:

1. Which tables are RLS-covered, which are intentionally global
2. The rationale for each non-covered table
3. What the boundary expectations are for application code reading/writing these tables

If the decision is "add RLS", this issue becomes a parent for the implementation PR. If "keep global", the ADR is the final deliverable and this issue closes on merge.

References

Scope doc: rls-harness-scope-2026-04-22 Category F
Parent roadmap: security-tooling-roadmap-2026-04-22 (id 0d4007ce)