Perf: binary typed-array buffer marshaling (replace JSON __csArray for hot buffers)

[Singtaa]

Spun out of #106.

Typed arrays cross the JS<->C# bridge as JSON via the __csArray path (Array.from + JSON.stringify on the JS side; parse + per-element convert on the C# side). Fine for small buffers, but it dominates for large or high-rate payloads.

This is an enabler - schedule it with a consumer, not standalone

The JSON cost only actually hurts here:

• GPUBridge (G2) - compute.buffer.write() / .read() round-trip through JSON every frame (read polled ~60Hz); scales with element count.
• WebSocket (N1/N2) - per-message dispatch builds + evals a JS source string; binary frames additionally pay a base64 round-trip.
• PainterBridge (D) - already ships with the JSON buffer, but painter buffers are small, so this is only a micro-opt there. D is not a reason to do this on its own.

Scope

• First check whether the existing Uint8Array/ArrayBuffer binary marshaling (from the WebSocket work) can be reused, vs. needing a new native path.
• Provide a binary Float32Array (and byte) entry point that copies raw bytes instead of JSON, and wire it into the buffer paths above.
• Touches the native quickjs_unity.c ABI, so it needs a native rebuild across platforms.

Recommendation

Do not schedule standalone. Pick it up as part of whichever of G2 / N1 / N2 gets prioritized - those are where the JSON round-trip is actually a measurable cost.