agent, control-plane-api: publications authorize via Snapshot

[bbartman]

Part of #2781. Migrates publications' authorization enforcement off internal.user_roles() SQL and onto the in-process authorization Snapshot, following the pattern established for discovers in #3373 and #3386.

This first commit is the red-green test phase:

• Three characterization tests pin today's SQL-enforced behaviors, which must survive the swap unchanged: drafting a spec requires admin to its name; a data-plane the user cannot read is indistinguishable from a missing one (both when explicitly requested and when reached as a storage mapping's default plane); and an unreadable-but-unused storage-mapping plane is silently tolerated.
• One test is committed RED: test_publication_no_data_plane_requests_snapshot_refresh asserts that a denied data-plane cancels the Snapshot's revoke token to request an early background refresh, which the SQL path never does. Following commits turn it green.

The full migration plan is in the first comment below. Draft until the remaining commits land.

[bbartman]

Migration plan: publications onto the authorization Snapshot

RLS surface reachable from publications

Every internal.user_roles() evaluation in the publications call chain is reached through three touchpoints, all publications-private — no function copies are needed:

1. resolve_live_specs — user capability per catalog name. fetch_live_specs(..., fetch_user_capabilities=verify_user_authz, ...) evaluates a materialized user_roles($1) CTE; the Rust side then enforces admin-on-drafted-names and read-on-referenced-names. The SQL is already flag-gated, and every other caller passes false.
2. resolve_live_specs — data-plane name read authorization. The data_plane_names CTE filter (marked for strangling in agent: discovers authorize data-planes via Snapshot #3386). Note it runs unconditionally — controller publications (verify_user_authz: false) also rely on the system user passing this filter, so the Snapshot-based replacement applies to them identically, as PGControlPlane::discover already does.
3. ExpandDraft → get_connected_live_specs → fetch_expanded_live_specs. Computes user_capability per expanded row; Rust filters to admin. Single caller, single construction site.

Verified clean: the commit path (quotas, persist_updates, verify_unchanged_revisions), PruneUnboundCollections, connector image/annotation checks, resolve_inferred_schemas, and draft::load_draft have no user-scoped predicates. Out of scope: spec_capabilities (plain role_grants join, spec-to-spec authz, not user RLS), the RLS insert policies on publications/drafts (PostgREST-side), and the other user_roles users (storage-mappings directive, create_data_plane/update_l2_reporting ops/ checks, GraphQL).

Design decisions

• Snapshot threading follows the Discover precedent: DraftPublication carries a pinned &Snapshot; PublicationsExecutor gains a snapshot_watch and pins one Snapshot per poll, so authorization cannot flip between expand, build, and retry attempts. The other DraftPublication sites (PGControlPlane::publish, create_data_plane, update_l2_reporting, test harness) update mechanically — PGControlPlane and the harness already hold the watch.
• ExpandDraft holds the same pinned snapshot as a field rather than changing the Initialize trait signature.
• In-process equivalents: tables::UserGrant::get_user_capability is a drop-in for the SQL max(capability) where starts_with(...); UserGrant::is_authorized(..., Capability::Read) replaces the data-plane name filter. Error strings are preserved exactly; a denied data-plane name stays indistinguishable from a missing one.
• Accepted behavior divergence (Storage mapping wizard private plane grants #2848): user_roles() only walks the grant graph downward, while Snapshot authorization also walks upward to ancestor subjects. Sub-prefix admins therefore become correctly more permissive against ancestor-subject grants (private data-plane prefixes in practice). This is the intended fix, not a regression; the characterization tests pin mainline behavior only.
• Fetch/decide split: live_specs fetches are pure data reads; authorization is evaluated in Rust at each decision site against the pinned Snapshot, never synthesized onto rows as capability fields (the field synthesis attempted in Update validation/publication to use snapshots #3155 is what produced its legacy-capability-promotion review finding). Authorize-before-fetch applies only where the query keys are user-chosen names and a denial must be indistinguishable from absence — data-plane names. This converges on the same end-state shape as control-plane, agent: move catalog authorization in-process against a pinned Snapshot (2/7) #3342's get_connected_live_specs, minimizing rebase friction with the stack.
• Staleness: on any Snapshot-evaluated authorization denial that fails the publication — a drafted name the user can't admin, a referenced name they can't read, or a denied data-plane — cancel the Snapshot's revoke token to request an early background refresh, so a manual retry after a fresh grant succeeds sooner. (Data-plane denial matches discovers; the user-capability cancels go further, since under SQL those checks were never stale.) ExpandDraft's admin filter does not cancel: filtering merely narrows expansion and doesn't fail the publication. The full stale-snapshot deferral (PublicationState.awaiting_snapshot_after, already pre-staged as dead code) stays a follow-up PR.

Commit sequence

1. ✅ Red-green tests pinning current publication authorization behavior (this PR's first commit).
2. ✅ Thread the pinned Snapshot: PublicationsExecutor gains snapshot_watch, DraftPublication carries the snapshot; mechanical updates at the other construction sites. No behavior change. (fc23a15d70b)
3. ✅ resolve_live_specs user capabilities via Snapshot: flip fetch_user_capabilities to false, compute with get_user_capability; revoke.cancel() when a denial pushes an authorization error. (d3d2fe3e262)
4. ✅ Data-plane names via Snapshot: delete the marked SQL block, partition names in-process, revoke.cancel() on denial (turns the RED test green). (4199c8291bb)
5. ✅ ExpandDraft admin filter in-process: fetch_expanded_live_specs becomes a pure data fetch — drop user_id, the internal.user_roles() subquery, and the role_grants subquery (nothing on the expansion path reads spec_capabilities; select a '[]' placeholder while the shared row struct still carries the field). get_connected_live_specs takes the pinned &Snapshot and filters per row via tables::UserGrant::get_user_capability. No revoke.cancel(): filtering narrows expansion, it doesn't fail the publication. (7180bb21602)
6. ✅ Strangle-complete cleanup: no caller passes fetch_user_capabilities=true anymore, so remove the flag, the user_roles CTE, and the user_id parameter from fetch_live_specs (it fed only the CTE), and delete the now-reader-less user_capability field from LiveSpec. spec_capabilities and its role_grants join stay, resolve-path only: spec-to-spec authz remains out of scope. (1e141e363ea)

After this PR, the remaining internal.user_roles users are the storage-mappings directive, the ops/ admin checks in create_data_plane/update_l2_reporting, and the PostgREST _ext-view estate.

[bbartman]

Decision: Snapshot grant-walk helpers (review follow-up)

Code review flagged the recurring argument bundle (&snapshot.role_grants, &snapshot.user_grants, user_id, name) at this PR's authorization decision sites as a data clump / message chain.

Decision: hide the walk behind methods on the object that owns the data — Snapshot::user_capability(user_id, name) and Snapshot::is_user_authorized(user_id, name, capability) — and convert only the call sites this PR introduces (the three resolve_live_specs checks and the get_connected_live_specs expansion filter). The pre-existing bare tables::UserGrant::* call sites (server/*.rs, discovers, live_specs::partition_by_authorization) are deliberately left as-is and migrate opportunistically as later #2781 slices touch them — same strangler discipline as the rest of the series. This also pre-lands the end-state shape from the stack-2 reference implementation, which put these helpers on Snapshot.

[bbartman]

One of the other things that is absent here is that we still need to refactor out spec_capabilities but I'm leaving that for another PR/follow up.