🤖 fix: a draft write reply from a new backend with lower revisions puts old text back while the user types #6438

Found while fixing a Storybook flake in #6437 (Refs #6389). The readiness reviewer confirmed it in the code. I did not reproduce it with a real backend.

What happens: DraftStore.setClient resets the receiver and the retry timers when the backend changes, but it keeps each entry's serverView. applyWriteReply keeps that saved view unless reply.revision >= serverView.revision (src/browser/stores/DraftStore.ts, around line 2036), and then calls applyServerState with the old saved view.

So if a new backend answers with lower revision numbers than the old one, every write reply puts the old saved text back over what the user is typing. The real backend seeds revisions from its start time, so a normal restart is safe. A new backend whose clock is behind (for example after a clock change or a different host) would trigger it.

The Storybook drafts mock had exactly this bug: each story's client restarted at revision 1 while the page kept one store, and the Phone story lost typed text. #6437 fixed the mock, not the store.

Proposed fix:

1. When the receiver ID changes (a new backend), drop or rebase each entry's serverView and revision.
2. A store test: a write reply on a new client with a lower revision must not overwrite the typed text.

Owner: coordinator desk.

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $1622.63