perf(aws-lambda): cloud renders plan without reading video bytes and start chunks sooner - #6194

What changed

A cloud render's plan no longer touches video bytes, and each chunk starts capturing sooner. Six changes, each in the code it names:

1. Stored probe facts. sites create stores each video's ffprobe JSON, its final-frame time and its last packet length beside the video, keyed by content hash (like the audio sidecars). The plan reads that instead of probing the file over the network.
2. Frame counts without decoding. A window that ends a second or more inside its source takes the expected frame count. A window that reaches the source's end takes it from the stored final frame (constant frame rate; a late-starting video stream only when its last packet is a full frame, otherwise the old tail decode runs). Remaining tail decodes run 16 wide (HF_TAIL_PROBE_SLOTS).
3. Chunk encode overlaps capture for closed-GOP chunks (canEncodeWhileCapturing no longer excludes lockGopForChunkConcat); output is byte-identical to encoding after capture (new test).
4. Locked warmup ticks stop sleeping once the page is ready. The tick count stays 60, so frame times are unchanged; each Chrome start saves ~2 s, twice per chunk.
5. Logs: [plan] extract phases, [audio] phases (the plan never passed its logger to the audio stage).
6. Engine package size budget raised to 456,055 packed / 1,526,873 unpacked bytes (5% over measured): the facts reader and tail-count code live in the engine.

What I measured (93-cut 4K edit, 6 sources, 22 GB, 840 s, cold functions, real sites create)

• Frames and audio are identical to 0.8.190 on every run (21,000 frames, same md5 per run).
• 30-minute 1080p edit, 204 chunks, real sites create (15 s): wall 38.5 / 40.7 / 38.9 s, $0.547 / 0.531 / 0.550, plan 2.5-2.9 s; the 54,000 frames and the audio are identical across the three runs. The released 0.8.190 renders it in 41.9 s / $0.580 (one cold run, the first after a redeploy) with the same frames and audio, so on a single long clip this PR is about 6% faster and 7% cheaper; the big win is the cut-heavy multi-source edit above.
• Warmup change: 4 distributed-simulated fixtures (CSS keyframes from t=0, a video at frame 0, a web font, GSAP) rendered with and without the sleeps: 0 differing frames, identical final mp4s.
• End-window count: 8,037 randomized windows against real ffmpeg: 0 wrong, 3 declined (fall back to the decode).
• Red then green: remoteTail, tailCount, encodeWhileCapturing, warmupTicks, plan audio-log tests each fail without their change.

What I did NOT exercise

• The stored final frame is used only when the plan's ffprobe has the same major version as the one that stored it (otherwise the plan probes the tail itself). The stream metadata JSON is still trusted, and the md5 runs above used a sites create ffprobe of the same build as the Lambda's, so they do not exercise a version mismatch.
• Sites made before this change have facts without the last packet length: their end windows still decode the tail (no regression, no speedup) until sites create runs again.
• A late-starting video whose last packet is short, VFR sources, HDR and color-converted windows: all fall back to the old decode.
• GPU hosts and non-Lambda targets for the warmup change; the frame check ran on a 4-vCPU SwiftShader host and on Lambda.
• Cost is flat to slightly lower per render (Lambda-seconds), not a large drop; the chunk time (~27 s x 254 chunks) is the remaining lever.