fix: patch WebM Duration header on streamed recordings (stacks on #617)

[neurot1cal]

Stacks on siddharthvaddem#617. Resolves the duration-metadata regression I flagged in my review (finding siddharthvaddem#2).

Problem

After siddharthvaddem#617, streamed .webm files save successfully but with no Duration EBML element. ffprobe reports duration=N/A and bit_rate=N/A. The editor opens the file but every control that needs a timeline breaks: seek bar reads 0:03 / 0:00, the timeline panel says "No Video Loaded", scrub/trim/zoom blocks have no time basis.

This was the user-felt failure mode for the long recordings siddharthvaddem#617 set out to save: pre-PR they got nothing; post-PR they get an uneditable file.

Fix

Patch the Duration header on disk in the main process after WriteStream.end() resolves. The renderer can no longer run fixWebmDuration(blob, durationMs) because the blob no longer exists, but the same library exposes a parser-level API (fixParsedWebmDuration(WebmFile, durationMs)) that operates on a Uint8Array — which works fine in Node.

Reads the whole file into a main-process Buffer, patches, writes back. Same memory footprint as the pre-PR renderer path, just on the side without V8's heap cap. Adds ~1–5 s to stop time depending on file size.

Verified locally

• 90-second streamed recording on PR fix: stream recording chunks to disk to support recordings longer than 10 minutes siddharthvaddem/openscreen#617 head:
  • before: duration=N/A, bit_rate=N/A, editor reads 0:03 / 0:00
  • after: duration=90.862000, bit_rate=10201352, editor reads 0:00 / 1:30, timeline populated, zoom blocks land on real timestamps
• npx tsc --noEmit — 0 errors
• npm test — 18 files, 151/151 passing (same as baseline)

Best-effort by design

If fixParsedWebmDuration returns false (no Info section, or already valid) or any I/O fails, we log and return without throwing. The file is still playable — decoders walk frames sequentially regardless of the Duration field — so a patch failure is a degraded UX, not a broken recording. Surfacing the failure to the user is a follow-up.

Possible alternatives if size becomes an issue

• Head-only patch. WebM Info segment lives in the first ~64 KB. Read just the head, rewrite the Duration element, splice. ~50 ms regardless of file size, but ~80 lines of careful EBML byte-shifting and higher subtle-bug risk.
• ffmpeg -c copy remux. App already ships ffmpeg per the fix: stream recording chunks to disk to support recordings longer than 10 minutes siddharthvaddem/openscreen#617 review. Slower (~10–20s on a long recording) and doubles disk I/O, but zero new code surface.

I went with the simplest variant for the first cut. Happy to pivot if the wall-time on stop matters in practice.

[neurot1cal]

Closing — folding this into a diff on the upstream PR (siddharthvaddem#617) instead of a separate PR, so everything stays on the original thread. Branch stays on my fork if it's easier to pull from.