subtitle burn: use ffmpeg-full for libass-dependent filter

[sonichi]

Summary

Fixes the root cause Susan called out early and I spent all afternoon chasing: the homebrew ffmpeg bottle for 8.1 on arm64_tahoe is built without libass, so the subtitles filter doesn't exist in the binary at all. Every burnLiveTranscriptSubtitles() call has been silently failing with:

[AVFilterGraph] No option name near '.../subtitle.srt'

because the parser was treating subtitles as an unknown option name rather than a filter. Four wrong theories chased before ffmpeg -filters | grep subtitles returned zero hits.

Fix

• Use the keg-only ffmpeg-full binary at /opt/homebrew/opt/ffmpeg-full/bin/ffmpeg for the subtitle burn specifically. ffmpeg-full bundles libass + libfreetype + fontconfig + 43 other deps.
• Fallback: if ffmpeg-full isn't installed, fall through to the narrow /opt/homebrew/bin/ffmpeg. Preserves behavior on MacBook / CI / any node without ffmpeg-full. The narrow call will fail loudly as before — strictly no worse than today's silent failure.
• Scope: only burnLiveTranscriptSubtitles() — all other ffmpeg call sites (narration mux via videotoolbox, record.py mux, etc.) keep using the fast narrow bottle. They don't need libass.

Install required (per-node, one-time)

brew install ffmpeg-full

~500MB–1GB, 5–15 min, 46 deps. Already done on Mac Mini (verified: ffmpeg -filters | grep subtitles returns the filter definition).

End-to-end test (already run on Mac Mini)

Ran the EXACT ffmpeg command with the new /opt/homebrew/opt/ffmpeg-full/bin/ffmpeg path against /tmp/sutando-recording-1776298340-narrated.mov + /tmp/sutando-live-transcript-subtitle.srt (both from owner's earlier failed test call):

frame=  229 fps= 58 q=-0.0 Lsize=    2900KiB time=00:00:15.20 bitrate=1563.1kbits/s

Output: /tmp/TEST-subtitled.mov, 2.9 MB, valid mov. ✓

Log delta

Success log now reports which ffmpeg was used:

[ScreenRecord] live transcript subtitles burned: /tmp/...-subtitled.mov (ffmpeg=/opt/homebrew/opt/ffmpeg-full/bin/ffmpeg)

Stacks on #355

Base branch: fix/subtitled-pending-false-positive (MacBook's #355). Neither PR alone is sufficient:

• fix: subtitled_pending false positive in open_file #355 makes subtitled_pending accurate (correctly gates on file evidence)
• open_file 18s polling timeout causes false 'recording not found' on phone calls #356 makes the burn actually produce output

Merge #355 first, then this.

History (for the retro)

Chased before landing here:

1. Wrong process restart (voice-agent vs conversation-server)
2. Stale local main (git fetch vs git pull)
3. Filter rejection (all-entries-filtered on short recordings)
4. Comma escaping in force_style (multiple backslash counts, none worked)

Susan raised "is it a dependency issue?" first. Owner also. I dismissed it twice. The trivial verification that would have landed this in 5 minutes: ffmpeg -filters | grep subtitles → zero hits → check ffmpeg -version → no --enable-libass.

🤖 Generated with Claude Code

[josuachavesolmos]

Reviewed by Sutando proactive loop.

APPROVE — minimal, surgical change. Only burnLiveTranscriptSubtitles() is affected; all other ffmpeg call sites verified untouched. Graceful fallback via existsSync check. Good observability with (ffmpeg=${ffmpegBin}) in logs.

One follow-up note:

• [MEDIUM] skills/screen-record/scripts/subtitle.py also uses the subtitles ffmpeg filter with bare ffmpeg — will hit the same libass error. Track as a separate issue.

Safe to merge after PR #355 lands (stacked dependency).

[sonichi]

MacBook review: LGTM. Auto-detects ffmpeg with subtitle filter support, cached after first probe, env var override available. Falls back to homebrew ffmpeg-full. Clean, no runtime cost after first call.

[sonichi]

Superseded by #392 (refactor: decouple open_file from recording logic). findFfmpegWithSubtitles() is folded into #392 as part of the unified refactor.