Schema evolution: subscribe-time migrate hooks

One stream registered at version: 2 with migrate: { 1: v1ToV2 }. Left panel subscribes normally (no schemaVersion on the wire, loader output passes through). Right panel uses subscribeAt(counter, { schemaVersion: 1 }) from svelte-realtime/test-client - the server's migrate[1] runs end-to-end on the initial subscribe response. Increment a counter and watch the right panel's row flip its provenance badge back to loader: the live publish is a raw v2 event, merging into the migrated base for that key.

Watching as Crispy Falcon (76f16be4) server version: 2

Live (v2): subscribed normally

no schemaVersion on the wire; migrate chain skipped.

subscribeAt { schemaVersion: 1 }: migrate chain ran

wire envelope claims v1; server runs migrate[1] on the loader output.

Bump a counter

Stream registration

Server: every subscribe-batch wire frame carries an optional schemaVersion. When set and less than the stream's version, _executeStreamRpc runs _migrateData(loaderOutput, fromVersion, toVersion, migrateFns) on the response payload. The chain composes forward through every migrate[N] in the registered map until it reaches the current version.

Client: _schemaVersion is closure-local in each stream subscription, set only by server responses. Production code can never present a stale schemaVersion from a fresh tab. The subscribeAt helper from svelte-realtime/test-client takes a stream and an explicit schemaVersion, walks the same wire path as a real reconnecting stale client, and returns a parallel Svelte store.

Production code never imports /test-client. The path is a loud signal that this is a debug / demo affordance.