fix: preserve playback through media processing failures

[richiemcilroy]

Short or sparse uploads can produce no thumbnail at the selected timestamp, and a thumbnail storage failure currently fails an otherwise successful video conversion. Retry the thumbnail once from the first frame of the local file within the existing timeout, and keep successfully uploaded videos complete when only thumbnail storage fails. Cancellation preserves its terminal state and emits one terminal webhook. Actual video failures still propagate.

Playback probes now cancel their response bodies after reading headers. If a preferred original upload disappears after processing, check the finished MP4 once so the player can recover. Existing playback during processing, authorization, source preservation, and transfer budgets are preserved. Add playback and budget coverage to the recording reliability CI gate.

Validation:

• Reproduced sparse-video thumbnail failure, unclosed probe bodies, and raw-preview cleanup failure before the fixes.
• 78 real-media integration tests passed across the media utilities and route suites, including full FFmpeg decode after thumbnail storage faults, one source GET and one MP4 PUT, failed output upload, and cancellation through the API.
• 373 recording/playback/budget contract tests passed in Linux CI.
• Scoped Biome, workflow YAML parsing, and diff checks passed.
• Media-server TypeScript diagnostics were compared with the base revision: the same five existing test-file diagnostics remain, with no additional diagnostics.
• Linux amd64/arm64 production-image verification passed in the existing PR workflow.

The final revision passed both Linux production-image decode/failure-recovery and long-recording performance checks, web typechecking, and self-hosting CI. The remaining cancellation race raised by automated review assumes interruption between the final abort check and the completion update; that path is synchronous, and the job manager also refuses changes to terminal states. The API cancellation regressions verify a single terminal webhook for both output and thumbnail upload cancellation.

Thumbnail decode failures remain fatal after the local fallback is exhausted: ordinary processed uploads do not yet have independent output validation, so broadening the optional-asset catch to include decoder failures would weaken the existing validity check. Storage failures are separated only after a thumbnail has decoded successfully.

Deployed as 05ebc5298ee750b71f4c9600f89dadd38f4d4456 on Vercel and Railway on September 7. All six media replicas passed health checks. A bounded production conversion of a 520,686-byte source returned HTTP 200 in 709 ms; the returned H.264/AAC MP4 passed a full FFmpeg decode. A completed uploaded recording also played to the end on the deployed share page with no media error. The initial live snapshot showed seven uploads cleared, six still uploading, and no upload errors; two new Instant jobs subsequently showed verified on their first attempt. These are initial rollout checks, not a sustained reliability or billing measurement.