fix(session): mint message ids and timestamps from one clock read - #46103

Issue for this PR

Closes #46102

Type of change

• Bug fix

What does this PR do?

A message's id and its time.created come from two different clocks. Identifier.ascending() reads Date.now() inside Identifier.create; each producer then reads Date.now() again for time.created. If the assembly path yields between the two reads, a message minted later can capture an earlier time.created than one minted before it.

Messages sort (time_created DESC, id DESC) (message-v2.ts:439). When time.created disagrees with mint order, history sorts wrong — and since time.created is the primary sort key, it sorts by the corrupted value.

Read the clock once, mint the id from that same timestamp:

const created = Date.now()
const id = MessageID.ascending(Identifier.create("msg", created))
info: { id, time: { created } }

Identifier.create already accepts an explicit timestamp, and its per-millisecond counter still applies on that path, so same-millisecond ids stay unique and strictly ascending. Applied at the message producers in prompt.ts, compaction.ts, plan.ts, and the debug/github CLI callers. The session-fork path is left alone — it clones an existing message's time on purpose — as are the ephemeral, never-persisted messages that never reach the ordering query.

Two neighbouring issues this is not:

• Run loop can never exit when message ids are not time-sortable (imported sessions loop until the provider 400s) #38791 was fixed by ordering on time.created instead of the id string. That makes ordering robust to id/time disagreement, but here time.created itself is wrong, so preferring it doesn't help.
• Identifier time field wraps on 2026-08-14T11:19:55Z — all sessions with history enter infinite response loops #39624 / Message IDs wrapped on 2026-08-14: new messages sort before old ones, silencing sessions and deleting history on revert #43303 (the 36-bit timestamp field wrapping every ~2.18 years) is a full id rollover — a different mechanism, untouched here.

Deriving time.created from the id (via Identifier.timestamp) is the obvious alternative and it's wrong: the id's embedded timestamp can predate a legacy row's separately-read Date.now(), sorting a new message ahead of existing data.

How did you verify your code works?

Red-first, through the real producer — the test asserts a minted message's embedded id timestamp equals its stored time.created, observed through SessionPrompt.prompt, not a hand-built fixture. Reverse-applying only the src/ hunks (test kept present) shows it fail against unmodified dev:

production reverted, test present:
  (fail) persists message IDs with their creation timestamp — Expected 1016, Received 1015
  58 pass, 1 fail
restored: 59 pass, 1 skip, 0 fail

500 ids minted at one explicit timestamp were all unique and strictly ascending. Full suite packages/opencode: 3396 pass / 0 fail. bun typecheck clean in opencode and core.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR