fix(inbox): preserve capture writes across list races

[Chris0Jeky]

Summary

• Record each successful batch result before reconciliation so pre-write detail polls cannot restore stale capture state.
• Let explicit/user-facing fetchItems loads resolve by their existing latest-load-wins request id even when a write completes mid-flight; background batch polling retains its write-generation guard.
• Avoid bumping list-write generation for uncached triage items that have no summary cache to update.
• Add deterministic regressions for the batch/detail, scoped-list/Keep, and uncached-triage races.

Proof

• npm exec -- vitest --run --maxWorkers=2 src/tests/store/captureStore.spec.ts -t 'capture write generation' (8 passed)
• npm exec -- vitest --run --maxWorkers=2 src/tests/store/captureStore.spec.ts (65 passed)
• npm exec -- vitest --run --maxWorkers=2 src/tests/composables/useInboxOrchestrator.spec.ts src/tests/store/captureStore.spec.ts (125 passed)
• npm run typecheck (passed)
• npm exec -- eslint src/store/captureStore.ts src/tests/store/captureStore.spec.ts (passed)
• git diff --check (passed)

This addresses the direct batch/list-generation defects in #2464. The separate LOW-2 cosmetic deadline warning remains intentionally open for a polling-policy follow-up.

Refs #2464

[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]

The connector usage-limit notice is informational, not a review finding. This PR is being checked through the independent coordinator review path; no code action is requested from this notice.

[Chris0Jeky]

Coordinator two-pass adversarial review at exact head d71e6ba: no CRITICAL/HIGH findings in the two changed files (captureStore.ts and captureStore.spec.ts). The PR's intended generation fixes are present: successful batch writes bump detail/list generations before reconciliation, uncached triage avoids a false list-generation bump, and explicit list loads retain latest-load-wins behavior. Hosted Windows Frontend Unit is red only in unrelated scripts/ci/dev-up.test.mjs tests (PowerShell reset-seed, PowerShell cancellation timeout, Bash Vite fallback); the failure trace does not touch this PR's changed files. Local targeted store proof was 65/65, with typecheck/ESLint/diff clean from the original pass. No fix is justified in this issue PR; the unrelated launcher cohort remains the tracked CI substrate blocker.

[Chris0Jeky]

Coordinator re-review after main refresh (head fce5139, base f965098): SHIP on the #2464 delta. The live diff remains limited to captureStore.ts and its store spec; the base refresh only incorporated already-merged #2548 and #2518 changes. The new hosted run is still pending, and the prior Windows failure was the shared high-volume launcher fixture now covered by #2556. No new correctness, security, or data-loss blocker found.

[Chris0Jeky]

Coordinator final re-review after #2556 landed (head bf08386, base b8878c9): SHIP on the #2464 delta. The live diff remains limited to captureStore.ts and its store spec; the high-volume launcher repair is now in main. Refreshed hosted checks are pending. No new correctness, security, or data-loss blocker found.