Prepare Program buffer before render startup and diagnose delivery misses

[iamfatness]

A live cold start on the RTX 4090 took 53.588 ms in the first render and missed Program slot zero's three-frame (50 ms) deadline. The Program buffer allocated devices, textures and shaders inside that timed render.

Prepare those resources before the render worker establishes its cadence anchor. Preserve the same frame deadlines, buffer depth, and lazy resize behavior. Add failure-stage logging for the ongoing #526 investigation and a real D3D test showing preallocation creates no frames, starts no delivery clock, and is reused by the first render. No reverted #419 foundations are reintroduced.

Validation on production commit 85ecaca0:

• Full Release native build: 995 tests passed, zero failed. Self-contained WinUI publish and runtime probe passed.
• All 19 checks completed without failure on the production commit. Later commits only record unranked backlog findings.
• Real installer validation passed install, runtime probe, shortcuts, duplicate/invalid-marker rejection, uninstall, user-file preservation, runtime removal, and manifest-escape refusal.
• Real Zoom meeting, eight 1080p source videos, 1920x1080@60 three-frame Program buffer, GPU-direct 6 Mbps RTMP stream. Eight Takes over four minutes, then four Takes over two minutes with corrected Program/Preview and Multiview arguments; no additional Program-buffer failures. Source/audio diagnostic drill passed all six checks.

The 1,800-second live observer completed: 895 samples spanning 1,799.031 seconds, 107,940 additional Program frames, one uninterrupted buffer generation, and zero underruns, scheduled delivery misses, GPU-not-ready events, overflows, output sequence gaps, source churn, or primary RTMP sender restarts. CPU render diagnostic misses increased by 1,223 and were absorbed by the buffer. Display-busy increased by 12; display and destination completion remain unverified. All 19 checks also passed on final documentation head 9efd6c3.

This fixes the observed startup allocation path, not every intermittent steady-state failure in #526. Simultaneous ISO recording lost queued video even on a stationary wall (#529). YouTube played 1080p60 and recovered to Excellent after a transient frame-rate warning, but browser playback drops were observed (93 of 102,468 at the final sample, latency 18.61 s). YouTube also briefly reported low audio bitrate, then recovered; receiver listening is pending. Display and destination per-frame completion remain unverified. Recording and end-to-end performance acceptance are not claimed; manual visual/audio validation remains pending.

The test harness also exposed the control API's programPreview/program-preview mismatch, recorded in #530. The corrected exercise verified the actual view mode. Keep this PR as a draft for manual validation; no public release is published.