fix(participant): detect stalled chunk production during recording

[JorimTheuns]

What

Adds a stale-chunk watchdog to useChunkedAudioRecorder: if recording is active (not paused) and no audio chunk has been finalized for 4× the timeslice (2 min at defaults), the existing interruption path fires — alarm sound, interruption modal, wake-lock release, PostHog report. A visibilitychange → visible listener runs the same check immediately when the participant returns to the tab, since intervals are throttled while hidden.

Interruptions now carry a reason (suspicious_chunks | stalled_no_chunks), reported as separate PostHog error-tracking issues and as a property on portal_recording_error, so the two failure modes can be tracked independently.

Why

The suspicious-chunk guard (v1.17.0) only counts chunks that arrive. When the browser suspends the page mid-recording — screen lock, backgrounding, the camera app seizing the mic — onstop never fires, so no chunks arrive and the guard never trips. On brief wake-ups the recorder flushes one corrupt-but->1KB chunk, which uploads (shows as "Unable to process this chunk" in the transcript) and resets the suspicious counter.

Production case (June 19, Android Chrome 149): transcript healthy until 6:47 PM, then a 2-hour flatline with three dead chunks and one 3-second fragment — no alarm, nobody in the room knew. PostHog error tracking shows the sibling iOS mode ("consecutive suspicious chunks", issue, 23 users in 10 days) but the stalled mode was invisible by construction.

Notes

• False-positive guards: baseline reset on startRecording and on resume-from-pause; watchdog skips while paused; fires at most once per session (shared hasCalledInterruptionCallbackRef).
• Suspicious-chunk branch refactored to share triggerInterruption() — behavior unchanged.
• tsc --noEmit clean; biome lint --diagnostic-level=error clean on both files (one pre-existing format nit on an untouched line in ParticipantConversationAudio.tsx is also present on main).
• Not covered by automated tests (recorder hook has none); manual test: start recording, lock the phone for >2 min, unlock → alarm + modal within seconds.

🤖 Generated with Claude Code

[github-actions]

Hi @JorimTheuns!

Thank you for contributing to Dembrane ECHO! Before we consider your Pull Request, we ask that you sign our Contributor License Agreement (CLA). This is only required for your first Pull Request.

Please review the CLA, and sign it by adding your GitHub username to the contributors.yml file. Thanks!

[spashii]

Holding until after the release. The detection is sound but the consequence is not: on a false positive this calls stopRecording() and hard-stops a live recording mid-session. The dominant trigger is visibilitychange -> visible, so a participant who backgrounds the tab for over two minutes on a browser that would have resumed correctly now gets stopped on return, where today recording continues. That is a regression in the path we can least afford during an event. Main has since shipped the host-side half (recording_health state machine + live mic-level audio_level beacons, shown as 'Audio stopped?' in the Monitor). Suggestion: rebase the participant-side alarm onto the getAudioLevel signal instead of 'no chunk in 2 minutes', and make the stalled path warn without stopping. The participant-side alert itself is a genuine gap worth shipping.