Fix HEVC VPS detection and Annex-B RTP framing

[dpiers]

HEVC VPS detection compared the mask before applying it, so type-32 NALs did not populate the VPS cache. Group the type extraction before comparison and reject short VPS payloads before MIME encoding.

The RTP consumer also recognized Annex-B input only when the pack began with a four-byte prefix. Recognize three- and four-byte prefixes plus extra initial zero bytes, then use the existing splitter. Otherwise valid Annex-B access units took the raw-NAL path and transmitted framing bytes as payload. The raw-NAL fallback and packetization helpers remain unchanged.

Add self-contained tests of the actual parameter-cache and public RTP paths. Frozen locally generated, decode-checked AVC/HEVC fixtures exercise single packets, fragmentation/reconstruction, mixed prefixes, extra leading zeros, timestamp/sequence wrap, input preservation and partial send failure. Tests capture UDP sends without starting a server or opening sockets; they need no camera, firmware, external bridge, FFmpeg or network at test time.

A separate ten-minute Ubuntu CI job now runs make -C tests test on the existing pull-request, master-push and manual triggers, with read-only repository permission. Hosted execution is pending approval; the existing cross-build/release job is unchanged.

Validation: make -C tests test passes on macOS Apple Clang and pinned Debian 12 AArch64 GCC 12, with native and ASan/UBSan builds. Each framing run passes 1,786 checks; each cache run passes 1,805 checks, plus the existing three-check corrected short-VPS guard case. The standalone framing regression fails semantically on the pre-fix consumer, and all four final builds serialize identical packet bytes.

This does not change RTP marker policy, parameter-set replacement or shared-timestamp concurrency, and does not claim actual network delivery or hardware acquisition support.

[wberube]

Thanks — the VPS fix is the real catch here, and I've kept it as-is: the mask just needed grouping before the comparison, and the SPS and PPS checks right below it already read that way.

For the framing, I've routed it through our existing nal_split() in place of the leading-zero scan. The scan is a reasonable defensive touch, but our HALs (SigmaStar/MStar, Fullhan, Ingenic, Grainmedia, Rockchip, HiSilicon) all hand over a plain three- or four-byte start code, so it doesn't come into play on our hardware — and since the splitter already locates the start code itself, leaning on it keeps the packetizer and the parameter cache on one path. I've opened #60 with just the source fix.

I'm going to hold the test harness and the CI job back for now, though — not a reflection on them at all. I'd just rather settle on one consistent way to lay out tests here before I take pieces of it into the tree, and I'd like to pick it (and your fixtures) back up once that's decided.