[wieslawsoltes]

Problem

The default WebSocket binaryType is blob. WebScene copied each binary frame into a Blob, then eagerly expanded every Uint8Array element into a comma-separated decimal string for its compatibility Blob#toString() cache. Unchanged Code OSS never requests that string, but its startup management stream contains about 11.87 MiB of binary frames and accumulated 650–729 ms of same-socket queue delay.

Change

Defer the existing Uint8Array string representation until a caller explicitly stringifies the Blob, in both top-level and child-frame implementations. Blob bytes are still snapshotted during construction, and explicit String(blob) returns the same result. Other typed views retain their existing immediate coercion behavior.

Add a release regression that constructs 48 × 262,144-byte Blobs, matching the observed 12 MiB startup workload, checks snapshot semantics, and compares construction with explicit expansion.

Validation

• 12 MiB Blob construction: 0.867 ms
• construction plus explicit expansion: 55.793 ms (64.4× slower, now pay-for-use)
• source mutation retains the original 1,3,5,7 Blob snapshot
• cross-socket marker: event 2
• 100-cycle WebSocket p95: 0.469 ms
• 20-cycle Ready p95: 1.775 ms
• 20-cycle Initialized p95: 8.962 ms
• FileReader p95: 0.030 ms
• FileReader under 4,096 timers: 0.318 ms after one timer
• protocol V8 heap returns to baseline

Full evidence is in docs/validation/binary-blob-lazy-string-20260921.md.

Fixes the identified binary-processing slice of #280. Product acceptance remains open until the exact package first-paint gate passes.