control-plane-api, tables: legacy decisions migrate to effective capability bits

[bbartman]

Task 4 of #3376 (stacked on #3406): every remaining request-path authorization and visibility decision that read the legacy read/write/admin label now keys on mask-attenuated effective capability bits. The legacy label is reporting metadata only, per decision 3 of the implementation plan.

Closes #3232.

What changes

• tables::UserGrant::get_user_authorization is a new single-name walk reduction returning both halves of a name's authority: effective bits accumulated additively across covering nodes (the decision input), and the max un-attenuated legacy label (compatibility metadata, None under bundles-only coverage). It supersedes get_user_capability, which is removed; the label semantics are pinned by the converted tests.
• LiveSpecRef: the six gated sub-resolvers (liveSpec, activeAlerts, alertHistory, status, lastPublication, publicationHistory) and the writtenBy/readBy minimum-capability pagination filter (previously an Ord comparison on the legacy enum) decide on effective bits. userCapability is null iff the bits fall short of Viewer; otherwise it reports the literal legacy column, with none standing in for bundles-only coverage.
• storageMappings no longer errors the whole query when a row's covering grants carry no legacy label (the storageMappings query fails for bundle-only grants (legacy-capability mismatch) #3232 bug); the row serves with userCapability: none.
• dataPlanes no longer panics on the same shape (.expect("capability guaranteed by pre-filter") trusted the legacy label where the pre-filter guarantees bits).
• Vocabulary normalization: alertConfigs and inviteLinks spell their filtered_authorized_prefixes thresholds as CapabilityBundle::Viewer / CapabilityBundle::Admin — bit-identical to the legacy enums they replace.
• The hardcoded Admin literals in createStorageMapping/updateStorageMapping responses stay: the field is informational, the mutations require admin-level effective bits, and no consumer reads it (the only userCapability consumer anywhere is the dashboard's auth-roles store on PrefixRef, untouched here).

Behavior changes

Thresholds are unchanged everywhere — only the decision input moves. The one deliberate behavior change beyond mask-correctness: bundles-only grants (capability = 'none', non-empty bundles) now work through liveSpecs, storageMappings, and dataPlanes listings, consistent with the walk-based checks that already admit them. PrefixRef already reports these as none; LiveSpecRef/StorageMapping/DataPlane now do the same.

Explicitly excluded per the plan: live_specs/db.rs's SQL-computed user_capability and get_connected_live_specs (async-executor-only; task 9 territory), and per-endpoint re-vocabulary (e.g. CreateInviteLink for invite links).

Tests

• tables: the combined reduction (bundles-only, masked attenuation, un-attenuated label, additive multi-path composition), plus the converted legacy-label pins.
• liveSpecs: a bundles-only viewer lists and reads specs (labeled none); writtenBy/readBy admit bundles-only-covered names and withhold unauthorized names; a sub-Viewer mask is refused at the root with the structured missing-capabilities body, so legacy labels are never a side-channel around the mask.
• storageMappings / dataPlanes: bundles-only listings serve with none where they previously errored/panicked.
• Unmasked parity: all existing snapshots unchanged.

Note

The 2026-08-26 Daily Sync recorded an open follow-up ("Discuss Legacy Bits", Brian with Dave and Greg) on exactly this gate-on-bits question. The written record — #3232, #2936's design comment defining capability: none for bundles-only grants, and the PrefixRef doc — all point the way this PR implements it; that follow-up is the venue to veto before merge.

[bbartman]

I need someone with more knowledge of the change from models::Capability::Read, to models::authz::CapabilityBundle::Viewer, because I don't know if these are the same thing or not. Claude seems to think they are.