fix(render): recover held network frames without fresh decode (#802)

[iamfatness]

Refs #802.

When an SRT/RTMP publisher stops, the decoder can wait for input while preserving valid CPU pixels. After preparation idle retirement or a replacement production consumer, that held token never refreshed until a new decode. Both real local SRT/RTMP controls fail replacement-consumer readiness with the same held source.

One preparation-only metadata worker per network adapter now refreshes stopped held tokens independently of decoder reads. It snapshots at most 64 channel descriptors per 50 ms pass, rotates larger sets, offers outside leaf locks, and commits only against matching CPU pointer, epoch, frame ID, observation time and prior token. Fresh decode wins. CPU/ISO bytes, source timing, decoder/audio counters and stalled-feed health remain unchanged; Program only polls descriptors. Shutdown joins the worker before channel retirement. Preparation off starts no worker.

Opt-in tests use real local FFmpeg H.264/AAC publishers, independent CPU-rendered pixel references, production consumer replacement, publisher restart/fresh epochs and source removal. Original setup failures (missing libx264), unselected-queue harness trial and stale-object trials remain retained rather than relabeled. The current harness selects arrivals while publication runs. Final head 7e65d7e passes both opt-in network tests and all 1,505 native tests. All 17 exact-head CI checks pass. Native tree aa7b6cd822fcc20d4c40dd8f0c2d35fc933a0a1a and binary hashes/source bundle are retained in artifacts/network-held-recovery-802-candidate.

This repairs held source preparation; it does not prove 60 fps output continuity, physical GPU reset, adapter migration, content latency, display/OS-camera delivery or installed/full-workload qualification. Defaults and installed beta remain unchanged. #802/#517 remain open; no beta is cut.