Bound sequence parser allocations to the input size

[fordred]

Summary

The HEIC sequence sample-table parsers (parseStsz, parseOffsets, parseStsc, parseStts in sequence.go) size their slices directly from 32-bit counts read from the file, without checking that the input can back them.

Reproduction: a 124-byte ftypmsf1 file with a pict track whose stsz box claims sample_count = 0x20000000 forces a 4.0 GiB allocation inside heic.DecodeConfig (measured via runtime.MemStats), before any decode or dimension check. A 10 MB body cap doesn't help — forged counts need no backing data. parseStts has the same amplification via an unbounded inner loop over a per-entry count.

Fix

Allocations are now bounded by data actually present in the input:

• parseStsz — per-entry sizes must fit the box payload ((len(p)-12)/4); a uniform table implies one byte of media data per sample, so its count is capped by the input size.
• parseOffsets / parseStsc — entry counts capped by the box payload length.
• parseStts — entry count capped by the payload; the expanded duration total capped by the input size.

parseTrak already has the full input in hand (data), so the input-size bound is passed down with no signature churn to the public API. Worst-case allocation is now proportional to the input (~30x, from the tables themselves), instead of unbounded.

Tests

• Same-package bounds tests for each parser with forged counts.
• TestDecodeConfigDoesNotAmplifyForgedSequenceCounts — the 124-byte forged container must fail fast allocating < 64 MiB (pre-fix: ~4 GiB).
• Legit sequences unaffected: full suite incl. TestDecodeAll (17-frame anim.heic) passes; benches and the wasm2go build are clean.

Found via KopiChange's review of a v0.7.1 consumer; the fix there guards at the boundary, this bounds the parser for every consumer.