obs-codec: AVC and HEVC header extraction writes straight into its bmalloc buffers (Fixes #1302)

[vpacher]

Stacked: on #1414 (the first two commits). Review only the last two commits; I rebase this PR after #1414 merges. It needs #1414 only for the shared counting allocator in the tests (alloc_count.rs).

Fixes #1302

What and why

obs_extract_avc_headers and obs_extract_hevc_headers grew three Vecs (packet, header, SEI) unit by unit and then copied each one into a new bmalloc buffer: 5 Rust heap allocations for a normal 256-byte keyframe packet. That fixed cost made the 256-byte cases about 1.25x slower than C. The larger cases were already faster than C because of the faster start-code scan.

A second scan only to get the output sizes would double the scan cost, so the fix scans once:

• nal::SplitUnits scans the start codes once. It adds up the three output sizes and keeps the ranges of the first 32 units on the stack (encoders write a few units per packet: parameter sets, SEI, slices). for_each gives the units again from those ranges. For a packet with more units it scans a second time, so it never allocates.
• packet::write_split_units allocates each output with bmalloc at its final size and copies every unit straight into it. It panics instead of writing past an output when the units do not add up to the sizes. Empty outputs stay NULL with size 0.
• avc::bucket and hevc::bucket name the unit classification that extract_headers used inline. split_headers keeps its Vec API for the tests.

No change to the C ABI or to any output byte (unit order, start codes, the packet/header/SEI split, bmalloc/bfree ownership).

RED → GREEN

• RED commit: f9c7830. rust/obs-codec/tests/codec/nal_alloc.rs counts Rust heap allocations on the calling thread (the counter moves to alloc_count.rs, shared with obs-codec: AV1 output shims write straight into their bmalloc buffers (Fixes #1304) #1414's av1_alloc.rs: one test executable can have only one global allocator). 1/4 pass (the no-start-code guard): AVC and HEVC 5 allocations each for a normal packet, more than one for a packet with very many units.
• GREEN: 57a11b7. 6/6, including a new test that compares the outputs for packets past the 32 stack-kept units with the C oracle byte for byte (AVC and HEVC, 64 KiB with thousands of units). The "very many units" test is tightened from at most one allocation to none. 83/83 obs-tests-codec (the AVC/HEVC parity proptests are unchanged), clippy -D warnings, cargo bench ... -- --test fixture checks. Tier 2 runs in PR CI.
• Benchmarks: record.py options, only the extract/ cases, 5 paired passes before and after, same host (Apple M1 Max) and load. Median Rust/C and paired range:

Benchmark	before	after
avc/extract/256	1.280x (1.203-1.295)	0.839x (0.824-0.850)
hevc/extract/256	1.261x (1.249-1.280)	0.789x (0.751-0.790)
avc/extract/16384	0.382x (0.375-0.408)	0.302x (0.295-0.307)
hevc/extract/16384	0.397x (0.389-0.413)	0.302x (0.297-0.305)
av1/extract/256 (not changed here)	0.483x	0.464x
av1/extract/16384 (not changed here)	0.663x	0.640x

The 256-byte regression was stable on this host (the issue's wide ranges came from a shared host). Both cases are now below C.

Checklist

• Base is master (or the description starts with a Stacked: note)
• I claimed the issue, or no one else has an open PR for it
• Characterization test (if the unit had none), then RED, then GREEN commits (parity and Tier 1 tests already cover the output bytes)
• User-visible change: its line in docs/features.md is added or updated (not applicable: no user-visible change; the Rust libobs is not shipped by default)
• (Optional) Local gate passed and the pushed head is stamped; otherwise PR CI runs the full suite
• Warning or flag changes (-W..., ratchets): not applicable
• Intentional differences from C listed in the parity test header and rust/README.md (ports): none

🤖 Generated with Claude Code