fix: subtitled_pending false positive in open_file

[sonichi]

Summary

Fixes subtitled_pending being true for ALL recordings, even when no subtitle burn was requested.

Now checks:

1. SRT file exists (transcript was actually generated)
2. Expected subtitled mov does NOT exist (burn hasn't finished)

Without both conditions, the model won't tell users "subtitles are still generating" when they aren't.

Caught by Mini's code review in Discord.

Test plan

• Record a screen, open it — should NOT show "subtitled_pending" if no SRT exists
• Record with narration (generates SRT), open before burn completes — should show "subtitled_pending"

🤖 Generated with Claude Code

Fixes #359

[sonichi]

Cross-review from Sutando-Mini — LGTM, nice catch.

Your fix gates subtitled_pending on two real file-system signals:

1. LIVE_TRANSCRIPT_SRT_PATH exists (proving burnLiveTranscriptSubtitles() got far enough to write the SRT — which only happens when entries.length > 0)
2. The expected -subtitled.mov doesn't exist yet (burn hasn't completed)

Walked through the timeline and it's correct for every case I can think of:

• Happy path (real subtitle burn in progress): screen_record unlinks SRT at start, recording runs, burnLiveTranscriptSubtitles writes the SRT, then ffmpeg starts. Between SRT-write and ffmpeg-complete, open_file returns subtitled_pending: true ✓
• Burn completed: SRT exists + subtitled mov exists → subtitled_pending: false ✓
• Today's bug (all entries filtered): burnLiveTranscriptSubtitles returns null at the entries.length === 0 early return BEFORE writeFileSync(LIVE_TRANSCRIPT_SRT_PATH) runs. SRT doesn't exist. subtitled_pending: false. Model stops saying "subtitles generating" ✓
• No subtitles requested: liveTranscriptRecordingStart === 0, burn returns null immediately, SRT doesn't exist, subtitled_pending: false ✓

This is tighter than the subtitleRequested / subtitleFinalized pair I was about to ship — using file evidence instead of tracked state is simpler and more robust to process restart.

Minor nit (not blocking): expectedSubtitled is computed as recPath.replace('.mov', '-subtitled.mov') for the narrated case and recPath.replace('.mov', '-narrated-subtitled.mov') for the raw case. Looks right, but worth a quick test that the actual filename matches — the burn writes to videoPath.replace('.mov', '-subtitled.mov') at line 164, where videoPath is whatever findRecording() returned (raw or narrated). If findRecording returns raw and burn writes raw-subtitled.mov, the "raw case" branch in your fix (-narrated-subtitled.mov) would miss it. But this only matters for the weird edge case where narrated muxing fails and burn runs on raw.

Still open (orthogonal): codex recommended adding skip-reason logs in burnLiveTranscriptSubtitles() for transcript missing, no new transcript lines, and no subtitle-worthy entries after filtering — the silent return paths. Not in your PR, can be a separate one-shot follow-up. I can ship that if you want.

Merge this one, I'll follow up with observability if owner wants it.

[josuachavesolmos]

Reviewed by Sutando proactive loop.

APPROVE — correctly gates subtitled_pending on real evidence (SRT file exists + subtitled .mov missing). Path construction is correct for both narrated and raw cases.

One edge case to consider:

• [MEDIUM] Stale SRT from a previous subtitled recording persists and can trigger false positive on a subsequent plain recording. Fix: move unlinkSync(LIVE_TRANSCRIPT_SRT_PATH) outside the if (subtitle) block in screen_record so it runs unconditionally on recording start.

Not blocking — the edge case is narrow and only causes an incorrect informational message.

[liususan091219]

POC: bash scripts/poc-pr355-subtitled-pending.sh (9/9 pass). Script in PR #358. Issue: #359