fix(runtime): tighten audio drift correction to ~80ms for narration

[miguel-heygen]

Summary

• Adds a strict sync tier (80ms threshold, consecutive-sample gated) to the runtime media path that catches accumulated drift from pause/play toggling
• Forces immediate sync on play/pause/seek/rate transitions via a one-shot forceSync flag
• Guards against false correction during initial buffering by requiring offset stabilization before strict sync fires

Closes #668

What changed

The runtime-owned media sync (syncRuntimeMedia) previously only corrected drift above 0.5s (and only on specific events). Stable drift between 80ms–500ms — common after repeated pause/play — persisted indefinitely. For narration-driven videos this caused audible A/V desync.

The fix adds three mechanisms:

1. Strict sync — 80ms threshold with 2-consecutive-sample gating (mirrors the parent-proxy path's MIRROR_DRIFT_THRESHOLD_SECONDS strategy)
2. forceSync on transitions — play/pause/seek/rate changes set mediaForceSyncNextTick which bypasses all drift thresholds on the next tick
3. Buffering guard — strict sync only fires when offset has stabilized (< 4ms/tick change), preventing false correction during initial buffer catch-up

Test plan

• All 694 existing tests pass (including the buffering-guard test that expects audio to stay at 0 during initial buffer)
• New test: forceSync corrects any drift above 20ms immediately
• Updated test: verifies strict sync fires after 2 consecutive stable over-threshold ticks
• Pre-commit hooks pass (lint, format, typecheck, commitlint)
• Manual: load a composition with timed narration, toggle play/pause 40 times, verify narration stays in sync

🤖 Generated with Claude Code

[miguel-heygen]

Superseded by #671 which includes the strict sync changes plus the full single-clock transport architecture. The strict sync threshold was tightened from 80ms to 40ms in #671, and the single-clock transport eliminates the root cause (two-clock architecture).