fix: address review feedback from #1333 and #1335

[mvanhorn]

What

Addresses all five review items from #1333 and #1335.

• gif-palette.png is now removed after the gif encode via try/finally, on success and on either pass failing (feat(cli,producer): add gif output format with two-pass palette encode #1333)
• The rendering guide's GIF section documents the 30fps auto-cap alongside the existing CLI warning (feat(cli,producer): add gif output format with two-pass palette encode #1333)
• REMOTE_GIF_IMG_SRC_RE in the studio server accepts http:// like the compiler's REMOTE_IMG_TAG_RE does, so http remote GIFs prep in preview too (feat(producer,core): play animated GIF inputs frame-synced via prep-time VP9 transcode #1335)
• Zero-delay GIF frames are clamped to the 10cs browser minimum when parsing metadata, so all-zero-delay stickers get a real duration and loop-expand across their clip window instead of playing once and freezing (feat(producer,core): play animated GIF inputs frame-synced via prep-time VP9 transcode #1335)
• Added a transcode-failure test asserting the propagated error names the failing transcode and carries the underlying ffmpeg error (feat(producer,core): play animated GIF inputs frame-synced via prep-time VP9 transcode #1335)

Why

Both reviews approved with these as named non-blocking concerns. Keeping them in one small follow-up closes the loop while the context is fresh. The three "minor observations" from the #1335 review (shared GIF test fixtures, a total-frame-count guard, hash-stability docs) are deliberately not taken here to keep this reviewable at a glance.

How

Smallest change per item: a try/finally around the two-pass encode in encodeGifFromDir, one regex character class, a normalizeDelayCentiseconds helper in the GIF metadata parser (clamps delays <= 1cs to 10cs, mirroring Chrome's playback timing), one docs sentence, and two tests.

Test plan

Rendered a composition to GIF with this branch and confirmed the output is valid and no gif-palette.png (or work-dir residue) remains afterward.

• Unit tests added/updated (zero-delay clamping in gif.test.ts, transcode-failure message in animatedGifPrep.test.ts)
• Manual testing performed (render + temp-file check above)
• Documentation updated (rendering guide 30fps cap)

[jrusso1020]

Approving at HEAD 1059106c. Small (+77/-38) follow-up that addresses all 5 non-blocking items called out on #1333 + #1335 R1s.

Verified each change end-to-end:

1. encodeStage.ts try/finally — wraps the two-pass palette+paletteuse encode so rmSync(palettePath, {force: true}) runs on success AND on either pass failing. The pre-existing code leaked the palette temp file unconditionally. force: true keeps cleanup safe when the first ffmpeg never wrote the palette before failing.
2. studioServer.ts regex https:\/\/ → https?:\/\/ — matches the compiler's REMOTE_IMG_TAG_RE which already accepts http; this is parity, not a new attack surface.
3. gif.ts normalizeDelayCentiseconds — Chrome clamps GIF frame delays ≤ 1cs to 10cs (100ms); this mirrors browser playback timing so all-zero-delay stickers loop-expand to a real duration instead of playing once and freezing. Logic is clean (returns 10 for ≤ 1, else delay), and durationSeconds reducer is now safely simplified since normalizeDelayCentiseconds guarantees non-negative output.
4. Docs — single sentence on the 30fps cap. Reads cleanly.
5. Tests — gif.test.ts pins the 10-frame all-zero-delay → 1s duration case; animatedGifPrep.test.ts pins that transcode failures propagate with both the failing input path AND the underlying ffmpeg error.

Miguel already approved at this HEAD. CI: lint, test, typecheck, build, Windows render+test, perf, fallow audit, CodeQL all green; regression shards still in-flight but that's normal for HF.

Matt, all yours to merge once the regression shards land.