Rule the visibility semantics of the four raw-iteration product surfaces (vault history, queue pending/config/claim)

[filipeforattini]

Parent

Spec #2107

Human decision needed

The #2138 contract step found four client-facing surfaces that read raw physical versions (no MVCC visibility), each flagged // TODO(#2138 follow-up) and pinned by the raw-iteration allowlist gate:

1. vault_versions / latest_vault_entries — VAULT HISTORY / VAULT LIST expose every physical version and never capture a snapshot (unlike the sibling KV readers). Plausibly the product contract (vault's job may be exactly exposing version history) — or an oversight.
2. load_pending_entries — QUEUE PENDING projects raw red_queue_meta rows straight to the client.
3. load_queue_config — push/receive/select read queue config raw; an uncommitted ALTER QUEUE is visible to concurrent operations.
4. meta_rows CLAIM callers — pending_message_ids / pending_deliveries_for_queue decide which messages a client is handed.

For each: rule whether raw-version visibility is the intended product semantics (document it in the code and keep the allowlist entry) or a defect (file the migration slice with the ruled semantics). Wire/driver implications for queue surfaces make this a maintainer call.

Acceptance criteria

• Each of the four sites has a recorded ruling (code comment naming the decision, or a follow-up migration slice filed).
• The allowlist gate entries match the rulings.