fix: post-merge follow-ups — demux hardening, edit lists, paced timing, load identity

[towneh]

Summary

Follow-up batch from review feedback on #1, #2 and #4 that reached me outside the PR threads after they merged. One branch as agreed, a commit per concern — five source commits, smallest first:

Malformed-input hardening. Remote MP4 reaches this parser (HLS/CMAF segments, VOD URLs), so stream-supplied fields now get the full treatment: tfhd/tfdt/trun reads are bounded to their box, a trun's declared per-sample table has to fit inside the box (with a sane per-fragment sample cap), the box walkers' size checks are rewritten in subtraction form so a size near INT_MAX can't overflow the comparison, run positions and sample-fit checks are 64-bit, and tick→µs conversion goes through a quotient/remainder helper instead of v * 1000000 / timescale (which overflows at crafted timescales). Also: ctts version 0 offsets are now read unsigned per spec, stz2 surfaces a clear unsupported-format error instead of starting playback with that track silently missing, and the worst-case Annex B output size moved into a shared basis_avcc_annexb_cap used by both MP4 paths and RTMP — RTMP previously allocated dlen + 64, which undersizes 1–3-byte NAL length prefixes and silently dropped the access unit.

Cleanups. Dead next_dts field, a stale fMP4-only header comment, a nested /* that warned on every TU.

Track edit lists (progressive). edts/elst were ignored, so a track delayed by an initial empty edit — common muxer output for A/V alignment — played that much early, permanently desynced. The classic walk now maps media time onto the movie timeline: empty edits become a presentation delay, and the first normal edit's media_time becomes the media-time origin (this also picks up ffmpeg's AAC priming edit, so audio/video line up sample-accurately). Fragmented MP4 is untouched — its timeline comes from tfdt.

Load identity scoped to every source replacement (C#, from #2's feedback). LoadGeneration advanced only in LoadUrl, so the resolver staleness guard couldn't see a newer load that arrived through LoadLocalPath, a direct LoadSource or a CPU Source assignment — it now advances on every source replacement. The LoadUrl metadata seed is keyed to the generation that armed it (a seed abandoned by a resolver-less or failed load no longer attaches to the next unrelated load), LoadSource no longer writes the metadata origin back into the caller's BasisMediaSource (it's retained player-side, trusted only while the same instance reloads with an unchanged Uri), Metadata returns a snapshot so external code can't mutate the live instance past OnMetadataChanged, and assigning a CPU Source clears the previous media's metadata instead of leaving it reported as current. The resolver contract is unchanged — capture LoadGeneration, resolve, compare, LoadSource — so the existing yt-dlp integration works as-is.

Pace delivery on decode time, not presentation time. The substantive one. Delivery pacing gated on the pts of whatever the demux thread submitted last, so a video AU whose composition offset exceeds the ~400 ms pacing lead slept the thread past its own decode turn — and the other track's earlier samples, queued behind it on the same thread, arrived late enough for the audio queue to trim them as stale. The video sink now carries the decode timestamp alongside pts; the gate holds on dts while the decoder and caption store keep receiving pts. Demuxers without decode timestamps (TS, RTSP) pass pts for both, which is exactly the old behaviour; RTMP forwards the FLV tag timestamp it already had. The progressive walk had the file-order variant of the same stall — a coarsely interleaved file (a chunk of video ahead of the matching audio) blocked the forward reader on paced video before it could reach the audio bytes — so samples whose file order runs ahead of their delivery turn now park in bounded per-track queues (32 MB; past the bound they deliver anyway, degrading to the old behaviour rather than buffering without limit).

Verification

Closed-loop demux harness (the same one used for #1/#4), old vs new:

• fMP4 CMAF concat regression: 360 video AUs / 564 audio frames, worst delivery-order A/V gap ~187 ms — unchanged.
• Progressive fixtures (a generated 12 s file and a real VRCDN recording): full demux, same counts; first audio pts is now −21.3 ms, which is the AAC priming edit being honoured rather than a regression.
• New edit-list fixture (audio delayed 2 s via an empty edit, ffmpeg -itsoffset 2 … -c copy): audio now delivers at 1.978 s (2 s minus priming) — previously it played at 0 and sat 2 s early forever. The verbose dump shows early audio parking in the queue and releasing in decode order while video streams.
• Trailing-moov error and video-only fixtures behave as before.

Windows DLL (MSVC 19.51) and Android arm64 .so (NDK clang 18) rebuilt from this branch.

Editor-validated (Windows desktop, Unity 6000.5.3f1, this branch consumed as the project's media player package):

• Live RTSPT regression — plays as before.
• CMAF HLS fixture — video with audio at real-time pacing (the path most affected by the decode-time gate).
• Progressive VOD (a real ~100 MB recording) — paced, end-to-end, A/V in sync.
• The edit-list fixture — audio joins at ~2 s as the elst dictates and plays clean to the end; previously it started at 0.
• Load-identity race — a direct URL loaded while a YouTube resolve was in flight wins and keeps its title (the stale resolve stands down); Reload keeps the title.

Console clean throughout.

Notes and limitations

• One residual load-identity gap is documented rather than closed: a direct LoadSource racing a resolver that already failed silently, with no other load in between, can still consume that load's seed. Closing it needs the continuation to carry an explicit token through LoadSource's signature, which didn't seem worth the API churn while the plain call has to stay resolver-compatible — the wrong origin lasts only until anything real loads.

• Gating on dts can release an AU up to its composition offset earlier than the old pts gate; typical offsets are a small fraction of the decode ring's span.

• Explicit tfhd.base_data_offset is still ignored (pre-existing — fragment placement derives from relative trun offsets). Kept out to keep this reviewable; it needs the moof's absolute stream offset threaded through.

• The harness and fixtures still live out of tree; porting them into the repo as a proper test target is a sensible follow-up if you want the repo to carry tests.

Heads-up: this conflicts with #3's rebuilt .so by construction; I'll rebase #3 and rebuild it once this lands.