Fix exact PolyTrack 0.6.2 browser parity

[TheSocialNetwork35]

Problem

The Rust wrapper diverges from PolyTrack 0.6.2's browser simulation even though both run the same physics WASM. Tiny differences in the JavaScript-side setup compound over long runs, so AI/TAS controls produced headlessly are not reproducible in the game.

The main parity differences were:

• one persistent WASM state buffer per Rust car instead of the worker's single shared 227-byte buffer;
• track/mountain allocations surviving longer and therefore changing the WASM heap allocation order before createCarModel;
• f32/glam quaternion and mountain calculations rounding earlier than JavaScript Number arithmetic;
• the worker's special sine-table value for π not being reproduced exactly;
• the WASI fd_write stub returning an error instead of success.

Fix

• Mirror the official worker's allocation and free order, including its shared output buffer.
• Perform start-transform and mountain-generation arithmetic as f64, casting only at the JavaScript Float32Array boundary.
• Reproduce Three.js quaternion/vector operations and the worker sine table exactly.
• Return success from the fd_write host stub.
• Expose update_car_raw for byte-for-byte differential testing.
• Remove the now-unused parry3d dependency and document the matching 0.6.2 WASM hash.

Browser differential proof

Compared against the official PolyTrack 0.6.2 Chromium simulation worker and polytrack_physics.wasm with only Forward held:

• finish frame in both implementations: 32,948
• states compared: 32,948
• bytes compared: 7,479,196 (32,948 × 227)
• differing bytes: 0
• SHA-256 from both runs: 2a5941172248cb5c00b6ead247a4ee07bbada6efd2c929f76030eb92a12b034e

A separate 1,000-frame run on the existing benchmark track also matched all 227,000 bytes.

Validation

• cargo fmt --all -- --check
• cargo test --lib — 55 passed
• cargo clippy --lib -- -D warnings
• RUSTDOCFLAGS='-D warnings' cargo doc --no-deps