perf(producer): overlap the plan step's audio work and hash files once - #5777

On a 30-minute 1080p30 project the distributed plan step on AWS Lambda drops from about 112 s to about 88 s. The audio mix now runs alongside hashing and uploading the project files, instead of in front of them, and each file is hashed once instead of up to four times. Plan artifacts and final videos are byte-identical to main.

What changed

• The audio mix overlaps the rest of the plan. Only the assembler reads the mixed audio. The plan used to run the full-length AAC encode first, then hash every file, then upload. Now buildLocalExecutionPlan moves compiled/ and the video trees into their final places first. It then starts the audio stage and, in parallel, streams a hash of those trees. planV2WithPublisher adds a whileAudioMixes callback that uploads the compiled/ blobs in that same window, using the existing 32-slot pool. artifactTargets ships every compiled/ file to every chunk, so each pre-uploaded blob is in the manifest; the new test checks this.
  • The audio stage resolves sources from the final compiled/ dir. Its contents are the same copy of the project, so the audio input bytes and ffmpeg args don't change.
• Hash once. A PlanFileDigests memo (sha256 by absolute path) is filled by that streamed prehash. It is then read by freezePlan, by the publication's plan-hash recompute, and by the per-artifact digests.
  • Freeze used to readFileSync each whole file, including the full 902 MB video. It now streams.
  • The S3 upload no longer re-hashes the local file before the PUT: the PUT already sends ChecksumSHA256, and S3 rejects bytes that don't match.
  • S3PlanV2ArtifactPublisher.putBlob returns early for a digest it already published, so blobs uploaded during the audio window are not checked again with a HEAD afterwards.
  • Chunks still verify every artifact they download.
• Stage timers. The plan logs one line per stage with its wall time ([plan] stage {"stage","ms"}): copy, compile, probe, extract, audio, prehash, prepublish, freeze, publication, upload, manifest. The Lambda handler adds plan_stage lines for download and untar.
  • Before this, the plan's 86 s after compile had no log lines at all.

What I measured

All runs used the same 30-min fixture: a 902 MB H.264 background, 29 MB of AAC, and a GSAP title, 16 chunks. Everything ran on one 10 GB x86 Lambda stack, swapping only the function code. Each plan was a direct invoke of the plan action.

• Main was measured with bench-only stage timers added and no other change.
• This PR's first commit was measured three times, and the final head twice more after the simplify pass.

• The tail after audio went from about 23.5 s to about 0.8 s. Peak memory went from about 5.1 GB to about 4.2 GB.
• The audio encode itself (about 64 s on Lambda) is now the critical path of the plan.

Byte identity:

• Full renders. The same 2-min project rendered end to end (plan, 16 chunks, assemble) on main, on the first commit and on the head. All three final MP4s have the same sha256 (138,129,659 bytes).
• 30-min plan on a Linux box.
  • Every published artifact is byte-identical between main and this PR, including the mixed audio.m4a, except meta/videos.json and plan.json.
  • meta/videos.json embeds the planner's random staging directory, so it also differs between two runs of main. With that one path normalized it is identical. plan.json differs only because it carries the resulting hashes.

Tests (bun, each file 3 runs in a row):

• New, failing on main: the compiled tree is published while the audio mixes, and that publish produces the same manifest as a serial build.
• New, failing on main: a digest taken earlier in the plan is reused, not recomputed.
• New, failing on main: a local file that no longer matches its digest is rejected by the S3 checksum.
• New, failing on main: the handler logs download and untar timings.
• New: the S3 publisher sends nothing for a digest it already published. Deleting the early return fails it.
• Each new test was also checked with one deliberate mutation of the code it covers, and failed.

What I did NOT exercise

• 30-min renders end to end. I did not run one; output identity at 30 minutes rests on the plan artifacts being identical, plus the 2-min full renders.
• The GCS planner. It shares the overlap and the memo but was not run against real GCS. gcsTransport still hashes locally before its upload, since GCS has no SHA-256 check on its side.
• The non-deferred plan path. Here the prehash also covers extracted frame trees, and it was only exercised by the existing unit tests.
• Downloaded or out-of-project videos. These ship under video-sources/ and are not pre-uploaded during the audio window, so they still upload after it. This fixture's video lives in the project, so it ships under compiled/.