[Bug] SerializationExtension bindings never reach the cluster wire / persistence

[pathosDev]

Docs (serialization/{overview,cbor,custom}) state that JSON/CBOR/custom bindings registered via SerializationExtension take effect on the cluster wire and persistence. In reality the wire uses JSON.stringify(envelope) (Protocol.ts) and the stores write their own JSON; SerializationExtension is imported only by serialization/*, index.ts, and http/Marshalling.ts. Either wire it through, or the binding feature is inert for wire/persistence. Surfaced by the docs↔source audit.

[pathosDev]

Partial progress via #888 (branch features/persistence-payload-serialization): the persistence half now works — every journal / snapshot store / durable-state store writes the tagged JSON tree format by default (Set/Map/Date/bigint/Uint8Array round-trip), and an explicit per-store withSerializer(...) option routes custom Serializers into persistence with self-describing __serialized__ framing (mixed-format streams decode per row).

Still open here: the cluster wire (Protocol.ts still does bare JSON.stringify, no serializer/manifest framing) and registry auto-binding (SerializationExtension bindings are still not consulted anywhere — persistence uses the explicit option, not findFor). Docs claiming bindings take effect on the wire remain wrong until the wire half lands.

[pathosDev]

Re-derived independently in the production-readiness review tracked in #913. The user-facing consequence is worth recording concretely, because it is invisible in single-node development and only appears on scale-out.

encodeFrame uses raw JSON.stringify (src/cluster/Protocol.ts:161), so round-tripping through the real encodeFrame/FrameDecoder:

sent	arrives as
new Map([['sku-1', 2]])	{}
new Set([...])	{}
new Date()	an ISO string — .getTime() throws on the receiver
new Uint8Array([1,2,250])	{"0":1,"1":2,"2":250} — binary destroyed
{a: NaN, b: Infinity}	{a: null, b: null}
bigint	throws at encode

Meanwhile JsonSerializer (used by src/http/Marshalling.ts) and JsonTree (used by src/persistence/storage/PayloadCodec.ts:48) round-trip all of these as real instances. So the same object survives the journal, survives an HTTP response, and is silently emptied by a tell to another node.

The docs contradict each other on this: docs/.../serialization/json.mdx:67 promises "Round-trip as real instances", while docs/.../cluster/refs-across-nodes.mdx:192 concedes "Map / Set — JSON serializes them as {}".

Two suggestions for scoping: until the serializer is wired through, failing loudly at encode with the offending path would be strictly better than shipping {}; and the local ask() path has the same class of defect from a different cause, filed separately as #925.