Use native typed arrays in Web Audio and DOMMatrix bindings #389

Part of #382 — v1.0.0 alpha readiness.

Problem

Several APIs accept or return ordinary arrays where the platform requires typed arrays:

• src/web-audio/AnalyserNode.res:12-L38: float methods need Float32Array, byte methods need Uint8Array.
• src/web-audio/AudioBuffer.res:11-L33: channel data and copy buffers are Float32Array.
• src/web-audio/BiquadFilterNode.res:16-L21 and src/web-audio/IIRFilterNode.res:16-L21: frequency-response buffers are Float32Array.
• src/geometry/DOMMatrix.res:47-L51 and the corresponding DOMMatrixReadOnly input/output methods: Float32Array conversions must use Float32Array.t.

Review Chromium probes rejected ordinary arrays for sampled analyser/copy/matrix methods, accepted native typed buffers, and confirmed typed return values. Filter signatures were reviewed against the platform contract, not separately browser-probed.

Acceptance criteria

• Correct corresponding input and output types across all listed families, including both matrix modules.
• Check related typed-array conversions for the same representation error.
• Add browser tests using OfflineAudioContext and typed buffers, asserting output data/buffer behavior rather than merely construction.
• Add typed DOMMatrix conversion round-trip tests.
• Add compile tests rejecting ordinary arrays where native typed buffers are required.

Performance/behavior constraint

Do not insert implicit copies for output-buffer APIs: the native operation must write to the caller's supplied buffer. Keep the scope to representation correctness, not a Web Audio API redesign.

Coordination

Use the regression infrastructure in #383. Source fixes can be developed in parallel, but this issue should close with executed regression coverage, not only a successful compile.