Message ordering breaks with clock-skewed IDs

[sjawhar]

Several places in the frontend compare message IDs with > / >= operators to determine ordering (session restore, fork boundaries, timeline queuing). This assumes IDs sort lexicographically in creation order, which breaks when messages arrive with clock skew.

Additionally, shouldExitLoop in prompt.ts doesn't guard against undefined parentID, which can cause the prompt loop to continue indefinitely instead of exiting.

Affected areas:

• session.tsx — restore/fork cutoff logic
• message-timeline.tsx — queued message filtering
• prompt.ts — shouldExitLoop parentID comparison
• session-turn.tsx — message boundary display

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• No issue template was used. Please use one of the three required templates (Bug Report, Feature Request, or Question). For a bug report, this means including fields like Description, Steps to Reproduce, OpenCode version, and Operating System.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

This issue might be a duplicate of existing issues. Please check:

• Web UI: client-generated message IDs cause infinite processing loop when client/server clocks diverge #11863: Web UI: client-generated message IDs cause infinite processing loop when client/server clocks diverge — describes the exact same root cause (clock-skewed IDs, shouldExitLoop condition failing, infinite prompt loop)
• Clock skew between client and server breaks prompt loop and message rendering #14236: Clock skew between client and server breaks prompt loop and message rendering — same issue with prompt loop and message rendering broken by ID timestamp skew
• Bug: Message ordering broken when client clock is out of sync with server #15657: Bug: Message ordering broken when client clock is out of sync with server — same message ordering breakage due to clock differences

If you believe this was flagged incorrectly, please let a maintainer know.

[sjawhar]

Duplicate of #11863. PR #17256 addresses this.