Context

Follow-up to #27495 (append-order guarantee for chat_messages.id) and #27619 (prompt query ordering), both merged. This PR applies the same id ordering to the transcript the user actually sees.

Why?

buildOrderedMessageIDs in chatStore.ts sorted by created_at, which is now() and therefore shared by every row in an insert batch. It builds orderedMessageIDs, which is what the transcript renders, so it re-imposed the ordering the backend PRs remove.

The failure needs the merge path, not a plain fetch. Initial REST hydration already sorts by numeric id before reaching the store, and Array.prototype.sort is stable, so a single correctly ordered response rendered correctly. But upsertDurableMessages copies the existing message Map, appends new ids, and re-sorts. Map iteration is insertion ordered, so when a refetch or reconnect merges earlier ids into a map that already holds later ones, the stable timestamp sort faithfully preserves the wrong order.

This also makes the store consistent with useChatStore.ts and api/queries/chatMessageEdits.ts, which already sort by id.

Changes

buildOrderedMessageIDs now calls toSorted with an id comparator inlined at its single call site, and the byMessageCreatedAt helper is gone. ChatMessage.id is a number in typesGenerated.ts, backed by a Go int64, so numeric subtraction is correct.

Testing

Two vitest cases, both verified red by restoring the timestamp comparator:

• sorts messages by id when created_at disagrees with append order returned [2,1].
• orders merged messages by id rather than by arrival returned [3,4,1,2], the exact inversion the merge path produces.

MergedMessagesRenderInIDOrder in ChatPageContent.stories.tsx covers the same merge path through the rendered timeline.

All 334 ChatConversation unit tests and the 4 ChatPageContent storybook interaction tests pass, and tsc -p . plus biome are clean.

Opened by Mux on behalf of Mike.