perf: inline @noble/hashes G1s/G2s into blake2 compress

[elicwhite]

@noble/hashes uses a pattern where G1s and G2s each return a fresh
{ a, b, c, d } object per call, destructured by the caller inside the
compression loop. In the chart-hasher path this is ~112 object
allocations per compress call (16 G-calls × 7 rounds for blake3),
dominating GC and showing up as 30–35% of scanner CPU time in the
profile.

Inline both G functions directly into compress, writing through the
v0..v15 locals via a scratch t temp. Semantics are byte-identical
to upstream — the inlining only removes the allocation wrapper.

Measured on the scan-perf autoresearch bench (2000 charts, 8 workers):
baseline (tip of perf stack):
mean 6.156 ms, p50 5.299 ms, p95 13.818 ms, p99 20.051 ms, max 33.346 ms
this patch:
mean 2.730 ms, p50 2.223 ms, p95 6.952 ms, p99 10.165 ms, max 16.368 ms
delta: −55.7% mean, −49.7% p95, −50.9% max
(2.26× speedup on scanner)

0 hash mismatches across 2000 charts — byte-identical ScannedChart
output. 442/442 scan-chart tests still green.

The patch is stored at patches/@noble+hashes+1.8.0.patch and applies
via patch-package on install.

[elicwhite]

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

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