perf: avoid BigInt alloc in calculateTrackHash binary layout

[elicwhite]

DataView.setBigInt64 forces a BigInt argument. In calculateTrackHash,
every tick and length — per tempo, time signature, star power, solo
section, flex lane, freestyle section, and note — allocated a new
BigInt object. For a dense track with 10k notes that's ~20k BigInt
allocations per track hash, feeding GC.

Charts are bounded: no tick or length approaches 2^31, let alone 2^63.
Replace each setBigInt64(i, BigInt(x), true) with a local helper
that writes two unsigned 32-bit LE words (low = x, high = 0). Output
is byte-identical — BigInt(x) for any non-negative int32 produces the
same 8-byte little-endian layout.

Measured on autoresearch-scan (2000 charts, 8 workers, 3-run avg):
previous: 2.80 ms mean (runs: 2.730, 2.876, 2.876)
this: 2.67 ms mean (runs: 2.634, 2.667, 2.717)
delta: −4.5% mean, max tail steady around 15-24 ms

0 hash mismatches across all runs, 442/442 tests green.

[elicwhite]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• perf: skip BigInt in blake3 b2Compress counter conversion #84
• perf: avoid BigInt alloc in calculateTrackHash binary layout #83 👈 (View in Graphite)
• perf: inline @noble/hashes G1s/G2s into blake2 compress #82
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.