fix(inbox): make background batch poll reconciliation tell the truth

[Chris0Jeky]

Summary

Four Inbox defects reported against the bounded batch-triage poll share one root cause: the
background reconciliation in captureStore writes store-wide state as if it were a foreground
load, and it reads that state as if nothing else could have moved it. All four fixes land in
pollBatchTriageCompletion, refreshTerminalDetails and the generation guards they read, so they
ship as one narrow change to one production file with one spec file.

• A batch whose immediate post-POST refresh exhausted its retries left listError set. Both skins
  hide every row behind that message, so the later successful quiet poll replaced the rows but the
  user still saw a broken empty inbox until pressing Retry.
• The single-item triage poll and an explicit detail load write a fresher summary through
  upsertSummary without recording a capture write, so the list write generation added in fix(inbox): preserve capture writes across list races #2517
  did not protect them. A slower batch-list response landing afterwards put the row back to its
  pre-poll status.
• Workload counts were refreshed only when every tracked item was terminal, so one lagging item
  held the sidebar and Home counts stale for up to a minute, and the 60-second deadline stop left
  them stale for good.
• refreshTerminalDetails reads details for items the user may not have open, and each read took
  the store-wide loadingDetail flag. The Legacy detail panel renders from it, so an unrelated open
  capture lost its body to a "Refreshing detail..." spinner and had its Refresh Detail button
  disabled by background work.

Closes #2305
Closes #2301
Closes #2303
Closes #2304

Changes

frontend/taskdeck-web/src/store/captureStore.ts

• [Frontend][Inbox] Successful batch poll recovery leaves a stale list error hiding rows #2305: the accepted success path of the background list read clears listError. Only that path
  clears it. An aborted response, one superseded by a newer explicit load or a newer capture write,
  and 401/403 either fail isCurrent() or land in the catch, so a foreground error stands.
• [Frontend][Inbox] Single and batch triage pollers can overwrite newer summary state #2301: upsertSummary stamps each per-item summary write with the shared monotonic generation
  (the counter recordCaptureWrite already used, renamed nextCaptureGeneration). The poll
  observes that generation before its request and applies the response through
  applyBackgroundListSnapshot, a per-row merge: the snapshot still owns membership, order, scope
  and the newest-first cap, and only a row whose own summary is newer than the read keeps its local
  value. No new timer and no new async path.
• [Frontend][Inbox] Partial batch-triage outcomes do not refresh the workload count #2303: the poll tracks which tracked ids it has already counted and calls
  notifyTriageCountChanged once per newly observed terminal outcome, replacing the
  all-terminal-only notification. stopAtDeadline sweeps the same way for an outcome whose tick was
  aborted before it reconciled. An outcome only counts once the poll has observed a post-enqueue
  list, the same trust rule isComplete uses, so cached pre-batch state never moves the badge. An
  unchanged snapshot notifies nobody.
• [Frontend][Inbox] Background batch reconciliation obscures an unrelated open detail #2304: DetailLoadOptions gains trackLoading (default true) and refreshTerminalDetails passes
  false. Foreground fetchDetail loading, error recording and toasts are unchanged.

frontend/taskdeck-web/src/tests/store/captureStore.spec.ts — a new background batch poll list truth block with 10 it declarations, 11 cases (one it.each covers 401 and 403). Each defect
spec was confirmed red against the current implementation before its fix.

Test plan

Verified (worktree .worktrees/codex-2305-inbox-poll-truth, head of this branch):

• npx vitest --run --maxWorkers=2 src/tests/store/captureStore.spec.ts — 76 passed (65 cases at the
  base commit, 11 added).
• npx vitest --run --maxWorkers=2 src/tests/store/captureStore.spec.ts src/tests/store/captureStore.integration.spec.ts src/tests/composables/useInboxOrchestrator.spec.ts src/tests/views/InboxView.spec.ts src/tests/views/paper/PaperInboxView.spec.ts src/tests/components/paper/PaperSidebar.inboxBadge.spec.ts — 6 files, 303 passed.
• npx vitest --run --maxWorkers=2 src/tests/resilience/degradedMode.spec.ts src/tests/resilience/slowApiAndStorage.spec.ts src/tests/property/storeResilience.spec.ts src/tests/composables/useInboxCounts.spec.ts src/tests/components/inbox src/tests/views/paper/inbox src/tests/composables/useCaptureQueueSync.spec.ts — 13 files, 257 passed.
• npm run typecheck — clean.
• npx eslint src/store/captureStore.ts src/tests/store/captureStore.spec.ts — clean.
• npm run build — built.
• git diff --check — clean.

Red-before-green, per defect:

• [Frontend][Inbox] Successful batch poll recovery leaves a stale list error hiding rows #2305 "reveals rows without a manual retry when a later background poll succeeds" failed with
  expected 'Failed to load inbox items' to be null.
• [Frontend][Inbox] Single and batch triage pollers can overwrite newer summary state #2301 both "delayed batch snapshot" specs failed with expected 'Triaging' to be 'ProposalCreated'
  and expected 'Triaging' to be 'Failed'.
• [Frontend][Inbox] Partial batch-triage outcomes do not refresh the workload count #2303 both count specs failed with expected "vi.fn()" to be called 1 times, but got 0 times.
• [Frontend][Inbox] Background batch reconciliation obscures an unrelated open detail #2304 "leaves the store-wide detail loading flag alone during batch reconciliation" failed with
  expected true to be false.

NOT verified:

• Playwright E2E (tests/e2e/capture-loop.spec.ts and friends) — needs a running stack; not run.
• No manual browser pass on either skin.
• Backend untouched, so no dotnet test was run.
• The Paper skin does not read loadingDetail, so [Frontend][Inbox] Background batch reconciliation obscures an unrelated open detail #2304's user-visible effect is proven at the
  store flag, not through a Paper render.

Boundaries and risks

• Only two files change, both under frontend/taskdeck-web. No docs, locale catalogs, backend, view
  or composable files are touched. Paper views and useInboxOrchestrator were read, not edited.
• trackLoading: false also applies to the refreshTerminalDetails call inside batchTriage, not
  just the poll. That is the same reconciliation for the same reason; it already ran with
  recordError: false and showToast: false.
• The count sweep replaces the unconditional notification on the all-terminal stop path. Every
  completed batch still refreshes counts at least once, because completion implies each tracked id
  was observed terminal; the refresh now happens when the outcome is first seen rather than only at
  the end, and an unchanged snapshot no longer re-notifies.
• latestSummaryGenerationById grows with the number of distinct capture ids seen in a session, the
  same shape as the existing latestDetailWriteGenerationById.
• Scope guard for [Frontend][Inbox] Successful batch poll recovery leaves a stale list error hiding rows #2305 rests on the existing isCurrent() rule (not stopped, not aborted, still the
  active request, no newer explicit list load, no newer list write) plus the orchestrator cancelling
  polls on a board or archived-history scope change. Pre-existing and unchanged here: batchTriage
  refreshes with an unscoped fetchItems() while the poll reads the scoped query.
• Detail-cache reads keep their existing guards (write generation plus shouldCache); this change
  adds monotonic protection for summaries only, which is what [Frontend][Inbox] Single and batch triage pollers can overwrite newer summary state #2301 specifies.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[Chris0Jeky]

Review gate (Codex credits exhausted, SC-9): one fresh-context adversarial reviewer on head 744f0cff0 (merge base 61e94f672). Verdict: SHIP. No CRITICAL or HIGH: the generation rename keeps #2517's equality-based guards intact, the per-row merge cannot pin a stale row, the counted-outcome sweep loses no refresh (isComplete implies isObservedTerminal), and trackLoading reaches no true foreground read.

Findings by bin:

• Fix-now: none.
• Tracked: [Frontend][Inbox] batchTriage refreshes the list unscoped and replaces a board-scoped Legacy inbox's rows (from PR #2567 review) #2570 (pre-existing, confirmed by the reviewer: batchTriage's post-POST fetchItems() is unscoped and replaces a board-scoped Legacy inbox's rows; for triage the scoped poll's first tick now corrects it within 3 s, for ignore / cancel it persists until the next scoped load) and [Frontend][Inbox] Poll-truth residuals from PR #2567 review: foreground loadingDetail unpinned, count-refresh amplification, summary-generation map growth, aborted negative control #2571 (MEDIUM: batchTriage's own foreground reconciliation no longer raises loadingDetail and no spec pins that; LOWs: up to ~20 GET /workspace/home calls per 60 s batch window, unbounded latestSummaryGenerationById, no "aborted" negative control for [Frontend][Inbox] Successful batch poll recovery leaves a stale list error hiding rows #2305, the caller-side nature of the same-scope contract, one spec comment mismatch).
• Declined: none.

Evidence at this head (from the implementation run): captureStore.spec.ts 76 passed (65 at base); six Inbox files 303 passed; thirteen neighbour files 257 passed; typecheck, scoped ESLint, build and diff check clean. Not verified: Playwright, manual browser pass, full vitest run. Round count: 1. Merge after ci-required green at this head.