[Desktop][Windows] Paginated thread history stalls on duplicate ordinal while rollout remains complete

Summary

On Windows Codex Desktop, one local paginated thread displayed only an older history snapshot although the canonical rollout JSONL still contained all later messages and the completed task. This was a local history-projection stall, not transcript deletion.

Environment

• OS: Windows 11 x64
• Installed Codex Desktop package: 26.820.9563.0
• Thread-recorded runtime: codex-cli 0.149.0-alpha.4.1
• History mode: paginated

Sanitized evidence

• The rollout JSONL remained parseable and contained exactly one repeated ordinal: ordinal 2186 appeared twice.
• The two records were event_msg/token_count and event_msg/thread_settings_applied.
• thread_history_projection_state expected ordinal 2187 at the byte offset where the second ordinal-2186 record began.
• The projection repeatedly logged an error equivalent to: expected ordinal 2187, got 2186.
• The SQLite projection stopped at an earlier ordinal while later user/assistant records and task completion remained present in the rollout JSONL.
• SQLite integrity checks were clean; there was no evidence of physical database corruption.
• After backing up the files, advancing only the projection byte offset past the duplicate record while keeping the expected ordinal at 2187 allowed the projection to catch up. The canonical JSONL was not modified.

Expected behavior

When a paginated history projection encounters a duplicate boundary ordinal, Codex should reconcile or rebuild the projection from the canonical rollout, or safely skip a verified duplicate metadata record. It should not silently leave the UI permanently behind the durable transcript.

Likely cause

This appears related to duplicate ordinal assignment during restart/resume or concurrent app-server writers, combined with a projector that treats a lower ordinal as fatal and has no automatic recovery path. Related reports include #40109 and #40178. Issue #32198 is related to Windows paginated-history handling but appears distinct: it concerns legacy tool_search_output parsing/replay UI freezing, not duplicate ordinals or a frozen SQLite projection.

Requested fixes

1. Serialize rollout writers and refresh the durable tail before assigning paginated ordinals.
2. Detect byte-offset/ordinal mismatches on startup and rebuild or reconcile thread_history_*.
3. Provide a supported history repair/doctor command.
4. Surface an actionable error instead of silently showing stale history.

Privacy

No thread ID, absolute paths, prompts, conversation content, credentials, or raw logs are attached.

Start by tracing the paginated history projector around thread_history_projection_state and its handling of duplicate event_msg records in the canonical rollout JSONL. Use the reported duplicate ordinal 2186 scenario to understand the byte-offset mismatch. Done means the projection safely reconciles or rebuilds, the UI catches up without changing the canonical JSONL, or shows an actionable repair error.