fix(app): order messages by position, not by ID string - #57581

What it does

Fixes a bug where Rewind in a forked session (or one with messages from the iOS app) hid the wrong messages, and committing the revert could drop the whole loaded transcript. The client decided message order by comparing message IDs as strings, but the server orders by seq, and IDs don't sort that way:

• Forked sessions copy messages as msg_<fork>_<seq>, so msg_x_10 sorts before msg_x_9. Staging a revert at msg_x_10 hid msg_x_9 too.
• iOS mints mixed-case IDs, and msg_A47D… sorts before every lowercase ID, so a revert there hid all earlier messages.
• On session.revert.committed, the splice looked for the first ID >= the boundary, cut at index 0 and dropped the loaded history.

The TUI transcript had the same string comparison, and the app's turn list dropped every turn when a revert was staged on an assistant message. Found in code review; each case is reproduced in the new tests.

How it works

Order comes from position in the message list, which is already in server seq order.

1. New messagesBefore(messages, id) in session-domain.ts returns the messages before the boundary. The staged-revert filters (selectVisibleSessionUserMessages, visibleTimelineMessages) and the new-tail-turn check in interaction.ts use it. A boundary not in the loaded list counts as older than all of it. selectVisibleSessionUserMessages now cuts the full list before picking user messages, so a boundary on an assistant message works.
2. revert.committed in @opencode/client cuts at the boundary's index. When the boundary isn't loaded, it cuts everything only if older pages exist; with the whole history loaded, a missing boundary means a sync already applied the revert, so nothing is cut. A cut from the first loaded message deletes the paging cursor's anchor, so the client rereads the message list instead of stranding older history.
3. The TUI's staged-revert filter in rows.ts uses a matching messagesBefore, shared with index.tsx, which already sliced by position. Inbox items can't be ordered against a message ID, so pending items that were cut with the messages are removed, and the inbox is reread from the server to learn which others it kept.

Risk

Client only (desktop app and TUI): what the timeline shows during and after Rewind, and the pending-inbox list after a committed revert. A wrong cut would show too many or too few messages after a rewind. The extra inbox reread happens only when items are pending at commit time. Each predicate is still one linear pass over the list; I didn't run the timeline benchmarks.

Proof

New tests cover forked (msg_fork_9/10/11) and mixed-case (msg_d4f1, msg_A47D) IDs. They also cover the paging cursor (boundary at the first loaded message, or in an unloaded page), a boundary already removed from fully loaded history, and an assistant-message boundary. Against the old code the revert-visibility and committed-revert tests fail, and the new cursor tests fail against the previous head; on the branch they pass.

• bun test src/session/session-domain.test.ts src/session/timeline/controller-projection.test.ts in packages/app: 20 pass
• bun test test/solid-data.test.ts in packages/client: 36 pass
• bun test test/cli/tui/session-rows.test.ts in packages/tui: 28 pass
• bun typecheck in packages/app, packages/client and packages/tui: clean
• bun script/lint-changed.ts origin/dev: 0 problems
• CI on dev: all 17 checks pass