[Frontend][Inbox] Successful batch poll recovery leaves a stale list error hiding rows

[Chris0Jeky]

Found by the completed current-head Codex review of PR #2299 and independently confirmed as MEDIUM/non-blocking.

When a batch-triage POST succeeds but its immediate list refresh exhausts retries, fetchItems records listError. A later successful quiet poll replaces the Inbox items and can reconcile the open terminal detail, but it does not clear that stale listError. InboxListPanel continues to prioritize the old error and hides the recovered rows behind Retry until the user acts manually. Server state and the open Legacy detail remain correct.

Acceptance:

• clear a stale listError only when a current successful background list response is accepted;
• do not let aborted, stale-scope, 401, or 403 responses clear a foreground error;
• prove immediate refresh failure followed by successful poll recovery reveals the rows without manual Retry;
• preserve the authoritative POST result, bounded polling, and auth behavior.

Refs #2230 and PR #2299 thread r3889030803.

[Chris0Jeky]

[Claude lane claim v2]
lane: alpha-product-trust (session taskdeck-alpha-85, Taskdeck-Alpha checkout)
issue: #2305
base: 61e94f6
residual acceptance: a stale listError recorded by the post-POST immediate refresh is cleared only when a current, accepted, successful background list response lands for the same scope; aborted, stale-scope, 401 and 403 responses never clear a foreground error; a deterministic spec proves immediate refresh failure followed by a successful poll reveals the rows without manual Retry; POST result authority, bounded polling and auth behavior unchanged
owned paths/modules: frontend/taskdeck-web/src/store/captureStore.ts; frontend/taskdeck-web/src/composables/useInboxOrchestrator.ts; frontend/taskdeck-web/src/components/inbox/InboxListPanel.vue (only if #2305 needs it); frontend/taskdeck-web/src/api/captureApi.ts (read; edit only if a response-applied signal must cross it); specs: 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
shared-path leases: captureStore.ts and useInboxOrchestrator.ts (capture store/orchestrator hot path), one writer for the whole #2301/#2303/#2304/#2305 family
parallel-safe work: second worktree codex-2524 (post-revision Review seam: useProposalRevisions.ts, ReviewDecisionRail.vue, ReviewMain.vue) touches no Inbox file
open PRs/branches/review threads checked: PR #2299 merged (origin of this family), PR #2517 merged 2026-09-04 (capture write generation guards; residual re-audited against it before editing), PR #2484 merged (#2044 scope replacement), no open PR or live claim on these files; a9 holds the ten open PRs, none of which touches the Inbox store/orchestrator
human or decision gates: none
status: active