[UX] Archived-board history polish residuals from #1973

[Chris0Jeky]

Follow-on polish for the archived-board history surfaces delivered by #1973. None of these
is an acceptance criterion of #1973 — they were classified non-blocking by the bounded review
of PR #2031 and are recorded here so they survive #1973 closing.

Recorded by the late exact-head review pass on PR #2031 (2026-08-24):

• Keep a hash-targeted PendingReview proposal inspectable as read-only history. Archived
  Review currently shows only Approved / terminal / expired records, so a deep link to a
  still-pending proposal on an archived board renders nothing.
• Expose pagination / truncation state beyond the current 200-record getProposals limit,
  so an archived board with more history than that says so instead of appearing complete.
• Hide or replace the Paper decision-shortcut guidance while in history mode — the keyboard
  hints describe actions the read-only rail no longer offers.
• Retain a non-mutating Paper stored-preview affordance for archived proposals.
• Reload proposals when entering history mode on the same board, rather than relying on the
  board-filter watcher alone.
• Wrap or collapse the Archive action rows at phone widths; they can wrap or clip today.
• Handle newArchive=true with newAutomation=false without dead navigation — "View
  decisions" can stay visible and then redirect through the route guard.

Refs #1973

[Chris0Jeky]

Adding one more residual, recorded LOW by the fresh-context adversarial review of PR #2076 and deliberately not fixed there:

• Paper capture-history same-row reopen re-mints the peek guard token. PaperInboxView.onTriageOpen guards its async peekDetail with the item id, so open row X → collapse → reopen X reuses the same token. A stale failed request from the first open can therefore paint a persistent error over the second open's successful load, until the row is toggled again. Display-only and self-healing; a per-request sequence number instead of the item id would close it.

[Chris0Jeky]

One more display-only residual from the #2076 review-fix round, recorded for completeness: the symmetric reverse of the fixed leak — a live-mode detail GET resolving after the user has entered archived history can still unshift a live capture into the archived list rendering. Unreachable as a write (archived mode suppresses every mutation control) and self-heals on reload; same fix family as the syncSummary flag if it is ever closed.

[Chris0Jeky]

Adding four more residuals from the Codex review of PR #2076, triaged against the repository severity bar and declined as non-blocking there. Three of them sharpen items already on this list rather than adding new ground.

• Force-refresh the Paper archived-capture read. PaperInboxView.onTriageOpen calls peekDetail without forceRefresh, so a detail already in captureStore.detailById (seeded by a Legacy open, or by triageItem's optimistic write) is returned from cache without contacting the API. Archived inspection can therefore show obsolete text, status, or provenance — including omitting a proposal link that now exists. openBoardScopedHashItem already passes forceRefresh: true for exactly this reason and is the precedent to follow. Display-only and self-healing on reload.
• Give each archived capture toggle a distinct accessible name. The aria-label added in history mode (inbox.history.detail.open / .close) replaces the button's inner timestamp and excerpt in the accessibility tree, so every collapsed row announces identically and a screen-reader user cannot tell which capture a control expands. This is a regression introduced by PR [Backend][UX] Disclose and expose archived board capture and decision history (#1973) #2076 — the previous label was Open capture ${item.id}, generic but at least unique per row. Interpolating the excerpt or timestamp into the localized label closes it.
• Archived Paper Review has no empty state. When an archived board has no settled proposals and the route carries no proposal hash, activeProposal is null, so ReviewMain — the only component that receives the read-only state and renders the archived-history notice — never mounts. The remaining empty state says there are no proposals on the "active board" and offers to restore the "full queue", with no indication that this is archived read-only history. Needs a history-specific empty state outside the active-proposal branch.
• Pagination applies to archived captures too, not only proposals. The existing pagination item on this list was written against the 200-record getProposals limit; useInboxOrchestrator.loadInbox() hard-codes limit: 200 as well, neither Inbox shell offers load-more, and the capture list API exposes no offset or cursor while the service clamps to 200. An archived board with more than 200 captures silently shows only the newest 200.

Also sharpening one item already on this list with the mechanism Codex supplied:

• The hash-targeted PendingReview item is worse in Legacy than the original note implied: LegacyReviewView.renderedProposals resolves the hash target only from visibleProposals, while openProposalFromHash finds the record in the raw list and so never marks it unavailable or clears the hash. The deep link therefore opens a blank Review page rather than falling back to the queue. Either preserve the pending record as read-only (as Paper does) or suppress the capture-history link when no inspectable decision exists.

[Chris0Jeky]

v0.1.2 release-artifact E2E finding (2026-08-25, packaged exe on an isolated data root): the Archive surface is palette-only. The archive confirmation dialog tells the user "Puoi consultarle da Area di lavoro → Archivio", but after archiving, neither the sidebar (including expanded Advanced) nor the Boards page offers any Archive link — Boards just shows "Nessuna bacheca" with no hint that an archived board exists. /workspace/archive itself works exactly as #2076 shipped it (disclosure text, View captures / View decisions read-only lanes, Restore), and Ctrl+K → archiv finds "Go to Archive", but a Guided-mode novice following the dialog's own instruction has no click path. Suggest: an "Archivio (N)" affordance on the Boards page when N>0, or a sidebar entry. Also observed (minor): the Review sidebar badge kept showing "· 1" for a while after the only proposal was applied and its board archived, then cleared on a later navigation — possibly a stale count refresh.