[Frontend][Review] Revision-metadata residuals from PR #2565 review: invalid gate does not cover the disputed number, failure-toast noise after a proven save, clear-half coverage, unbounded history map

[Chris0Jeky]

Non-blocking residuals from the two fresh-context reviews of PR #2565 (refs #2524, revision metadata truth in useProposalRevisions.ts), tracked here rather than fix-cycled. File references are at that PR's head b0421100d.

1. MEDIUM, needs a self-contradicting server. history.invalid is cleared by any response that is a self-complete chain 1..max (loaded.size === highestLoaded, ~160), which does not require the response to cover the number that was disputed. Scenario: GET [#1, #2]; GET [#1, #2, #2-alt] sets invalid and stores nothing; a stale pre-save GET [#1] is self-complete for max 1, clears invalid, and the composable republishes (2, rev-2, true) as authoritative for the very number the server contradicted. Same shape with an empty list after a conflict at number 1. Every trigger requires the backend to contradict itself, and ProposalRevisionConfiguration.cs:44 makes (ProposalId, RevisionNumber) unique, so the precondition is DB or serialization corruption. Fix direction: record the disputed number(s) instead of a boolean and require the clearing response to cover them, or soften the doc comment at ~135-138 (which currently claims the disputed number is covered) to match the implemented proxy.
2. LOW, toast noise. Because publishPersistedRevisionMetadata no longer bumps loadGeneration, a GET that main silently discarded on the generation check now reaches the failure toast (~286-288) even when the published metadata is correct and authoritative: a reviewer can see "Revision saved" immediately followed by "Failed to load revision history". The read did fail, so the toast is not false, but it may make a reviewer distrust a good save. No spec asserts the toast on this path.
3. LOW, coverage. Only the retain half of the new catch rule is pinned. The "non-authoritative, do clear" half is unpinned: the #2215 M-1 resync-failure spec asserts revisionsLoaded === false and no toast but not revisionCount === 0; one extra assertion there closes it. Deleting the two assignments inside the guard would likely keep the suite green.
4. Still open from [Frontend][Review] Revision metadata publish discards a newer in-flight GET; history.invalid latches permanently (from PR #2516 review) #2524 (3): revisionHistoryByProposal is unbounded across a queue walk.

Refs #2524, #2458, #2215, PR #2565.

[Chris0Jeky]

Lane note (alpha product-trust, Claude session): this issue was opened by the lane as a tracked non-blocking residual and the lane holds no claim on it. An open test-only PR from another session sits on it; the lane leaves that PR to its author and will not open a competing one. Under the interim rule recorded for D-12, the first recorded claim or open PR on an issue wins regardless of marker form.

[Chris0Jeky]

Coordinator note (2026-09-05, D-12 sweep): the Codex session's PR on this issue was reviewed by one fresh-context Opus 5 reviewer (record on the PR) and merged with a merge commit. The PR body used Refs, so this issue stays open; what merged and what remains, from the review:

• PR #2623 merged as 11eb5ec3e: item 3 (the #2215 M-1 resync-failure spec now asserts revisionCount === 0). Items 1, 2 and 4 remain.