fix: reduce recording source finalization scheduling delays

[richiemcilroy]

Long desktop Instant recordings currently schedule a durable Workflow step for every source checkpoint. A completed production recording spent 444.6 seconds between 494 checkpoint steps, in addition to 474.9 seconds executing them.

Batch up to 32 checkpoint advances, yielding once 15 seconds have elapsed after a completed page. Each page still reloads the current job, video, and checkpoint, renews ownership, and persists its revision before the next page starts. The existing storage concurrency, source identity checks, multipart recovery, upload acknowledgment, output verification, and media processing remain unchanged. An in-flight page keeps its existing timeout and is saved before yielding.

If an operation fails after saved progress, yield to a new durable step so the next checkpoint has a fresh retry allowance. Failures without progress still throw to the existing retry mechanism. Permanent source errors retain their existing blocked classification.

Validation:

• 423 tests pass across 19 recording reliability suites, including S3/Google Drive, multipart copies, source mutations, required audio, ownership, publication, playback, and upload receipts.
• Added fault tests for crashes, lost database/step responses, ownership loss, expired leases, late verification, elapsed/count limits, persistent failures, and intermittent failures across successive pages.
• Replayed four anonymized production timing traces through the actual batching step. The long S3 trace uses 31 steps instead of 494, with the same 493 checkpoint writes. Both short Drive traces use 2 steps instead of 5; the incomplete-source trace remains blocked.
• Scoped Biome, next typegen (including workflow compilation), tsc -b apps/web, and git diff --check pass.

The long trace estimates source preparation at 8m22s instead of 15m20s when retaining its measured execution times and average inter-step delay. The short Drive estimates improve only about 2 seconds. These are timing replays, not production measurements of this implementation; storage latency, downstream media processing, and transcription still take time.

No database migration, desktop release, or new environment variable is needed. The checkpoint format and workflow step name are preserved. This does not change processing during recording or the legacy upload handshake; acknowledging uncommitted uploads requires a separate client-aware change to protect older clients' cleanup behavior.

Confidence Score: 5/5

The PR appears safe to merge; no actionable correctness, security, or repository-rule issues remain.

Summary

• Processes up to 32 checkpoints per step and yields after at least 15 seconds of completed work.
• Reloads and revalidates recording state before every checkpoint advance.
• Adds timing replays and fault-oriented tests covering persistence, ownership, retries, and source-error classification.