TLDR

Roll back #3450 byte-for-byte on useMessageHandling.ts. #3450 tried to fix #3273 (a later user message sorting between two segments of the previous assistant turn) by pinning every split segment to the same turn-start timestamp, but that strategy conflicts with the tool-call timeline: tool calls carry their own arrival timestamp (strictly greater than the turn-start timestamp), so after #3450 every tool call sorts after both assistant segments instead of between them. The resulting "tool call jumped to the end" symptom is what users are currently reporting. Revert unblocks that regression; two focused tests pin the two conflicting invariants so the next fix has a clear target.

Dive Deeper

The webview (App.tsx) merges text messages (useMessageHandling.messages) and tool-call cards (useToolCalls map) into a single array and sorts by timestamp for rendering. Three producers write into that sort key:

1. Assistant seg1 — created by startStreaming(T_stream) using the extension-side Date.now() that rides on the streamStart message.
2. Tool call — created by useToolCalls.resolveTimestamp, which takes the ACP _meta.timestamp when present, otherwise the webview's Date.now() at event-arrival time. Always ≥ T_stream.
3. Assistant seg2 (the one created after a breakAssistantSegment()) — before fix(vscode-ide-companion): preserve split stream message ordering #3450, created with the webview's Date.now() at chunk-arrival time; after fix(vscode-ide-companion): preserve split stream message ordering #3450, re-uses T_stream.

#3273 — under React batching on Linux, Date.now() inside the setMessages reducer of appendStreamChunk can be evaluated later than the next-turn user message was pushed. That produces seg2.ts > nextUser.ts, and the sort wedges the new user bubble between seg1 and seg2.

#3450 — reused T_stream for seg2 so seg1.ts == seg2.ts; since the next user message's timestamp is always > T_stream, it can no longer slip between segments. This closed #3273 but locked every seg2 at T_stream, which is less than any tool call in the same turn — so tool-call cards are now appended at the bottom of the turn instead of between the two segments.

The two invariants are genuinely opposed under a single-timestamp sort:

Satisfying both requires a monotonic sequence number shared across producers (messages, tool calls, plan cards), not just smarter timestamps. That is out of scope for this revert — the goal here is to restore the more-visible tool-call ordering and pin the invariants down in tests so the next PR can be judged against both at once.

This PR touches exactly two files:

• useMessageHandling.ts — identical to cfe142e9a^ (byte-for-byte).
• useMessageHandling.test.tsx — rewritten with two focused cases (see Reviewer Test Plan).

Reviewer Test Plan

1. In packages/vscode-ide-companion, run npm run build.
2. npx vitest run src/webview/hooks — all 5 test files / 10 cases green, including the two new ones in useMessageHandling.test.tsx:
   • assigns the second assistant segment a newer timestamp so a tool call can sort between the two segments — a normal it, passes today.
   • keeps every assistant segment of a turn before a user message that was sent between segments (#3273) — marked it.fails and documents the known regression; will flip to a plain it once the monotonic-sequence fix lands.
3. Open the VS Code companion and send a prompt that emits tool calls mid-reply (e.g. "read file X and summarize"). Confirm the tool-call cards now render between the two assistant text segments instead of being appended after them.
4. Optional stress: send a follow-up user question quickly after a tool-heavy turn; Chat messages are displayed in the wrong order - when I ask a question, it appears ABOVE my previous answer, instead of below it. #3273 may reappear until the proper fix lands — this is the expected trade-off documented by the it.fails test.

Testing Matrix

Linked issues / bugs

Reverts #3450. Re-opens #3273 as a known regression pinned by the it.fails test; the next PR should close it together with the tool-call interleave invariant.