docs(ai-chat): state the transcript ordering contract for custom storage (#4917)

Adds an explicit ordering rule to the "Writing your own storage" list in
the transcript storage guide.

The ordering contract was implicit: the page said `put` for a known id
keeps its position and that `load` returns the whole conversation in
order, but never told an adapter author how to preserve order in a
row-per-message store, and never warned against a write-timestamp
column. That gap is easy to trip over (reaching for a `seq`/timestamp
column) because the contract deliberately has no sequence number, only
an order.

The new bullet states it outright: order is a transcript position, not a
write time; a document store gets it from `transcript.entries`; a row
store needs an order column set once when a `put` first inserts an id,
in `put`-arrival order, and left unchanged on an in-place replace; don't
sort by a write timestamp, because a replaced message must keep its
place and a mid-turn steering message sorts before the answer it shaped.

Docs-only. Verified against the runtime's `applyChanges`/`buildChanges`
in `transcriptStorage.ts`.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Author: ericallam

docs/ai-chat/transcript-storage.mdx

@@ -213,6 +213,7 @@ A few things to get right:
 
 - Pick one view and stay with it. Apply `changes` if you store rows, write `transcript` if you store a document; don't mix them within one save.
 - `put` for a known id replaces the message in place; position and ordering don't change.
+- Order is the message's position in the transcript. A document store gets it from `transcript.entries`. A row store needs an order column set once, when a `put` first inserts an id, following the order the `put`s arrive in, and left unchanged when a later `put` replaces that id in place. Don't sort by a write timestamp: a replaced message has to keep its place, and a steering message sent mid-turn sorts before the answer it shaped even though its row is written later.
 - `truncateAfter` and `remove` are idempotent. Applying a changeset twice gives the same result as applying it once.
 - `load` with no options returns the whole conversation in order. With `limit`, return the most recent messages and a `nextCursor` (the id of the oldest returned message) when earlier messages exist.
 - Scope reads and writes by `clientData` where your backend enforces tenancy.