Flight Payload Repeats Full Chunk URL List For Every Client Module Reference Causing ~29% SSR HTML Overhead

The Turbopack flight serializer emits the complete chunk URL array inline for every `I[...]` client module reference without deduplication. Since Turbopack assigns all client modules on a page to the same chunk group, every row carries an identical copy of the same URL list, causing payload size to scale as (number of client references) × (chunk group size).

1. `npm install`; 2. `npm run build` with Turbopack; 3. `npm run start`; 4. `node analyze.mjs http://localhost:3000/` which decodes `self.__next_f` and counts duplicate chunk URLs (minimal repro yields 117 chunk-URL strings, only 5 unique).

This is a breaking change to the internal flight protocol. Both server and client must be updated in lockstep; otherwise hydration will fail or references will resolve incorrectly. The new `J` row and reference-by-id semantics are not backward compatible with older Next.js clients. Rolling back requires reverting both serialization and parsing. Multi-version deployments (e.g., canary and stable mixed) must be avoided. Concurrent requests sharing the serializer instance can cause race conditions if the registry is not scoped per request; ensure each request has its own serializer instance. Also, dictionary entries must be ordered deterministically and emitted before any referencing row to avoid parse errors.