[fix] a dropped relay socket is a pause in the live transcript, not the end of it

[Lanznx]

Part 1 of #283 — the relay half, on iOS.

What was actually broken

The report is "a phone call ends the recording", and reading the code it was three things. Only one of them still is.

The relay never reconnected on the dictation path, and threw the gap away on the meeting path. DictationCoordinator turned any .closed into finishUp() and any .error into fail(message) — with the raw wire string (relay error 402: …) shown to the user. MeetingRecorder did reconnect (that landed in #272) but dropped the sink the moment the socket died, so everything said during the backoff was gone from the live transcript, and the new leg's offset was systemUptime - captureStartedAt — "now" — which files a gap's worth of speech after the words that followed it.

Can the relay resume a session? No. One socket carries one Soniox session; there is no resume token in the protocol (SonioxProtocol.swift — config frame, keepalive, finalize, and that is the whole upstream vocabulary), and SttRelayClient is explicitly single-use. So a reconnect is necessarily a fresh Soniox leg whose token clock restarts at zero. That is exactly what Options.idPrefix and Options.timeOffsetMs were put there for; what was missing was something to hold the audio across the gap and a clock honest about where that audio belongs. This PR does not paper over the lack of resume — it builds on the per-leg offset the protocol already assumed.

iOS audio interruptions: already fixed, left alone. AudioCapture (#272) observes interruptionNotification, routeChangeNotification, .AVAudioEngineConfigurationChange and mediaServicesWereResetNotification, rebuilds the engine rather than leaving a tap on a dead node, deliberately ignores the absent .shouldResume (which is exactly the "other party hung up" case), and runs a two-second watchdog for what iOS announces to nobody. That covers the reported case. I did not touch it.

What this PR adds

RelayAudioBridge (ParleyKit). The microphone's only counterparty. It forwards chunks to the current leg and holds them while there is none, bounded (45 s meetings, 20 s dictation) with drop-oldest, and on the next attach it hands the new leg both the held audio, in order, and the offset of its first held sample. Overflow advances that offset with the front of the buffer, so a leg is never told it is being fed audio it is not. attach takes a factory closure so the offset, flush and swap are one step the audio thread cannot land in the middle of.

ReconnectPolicy (ParleyKit). The 1, 2, 4, 8 … capped ladder and the attempt ceiling, in one place instead of a pow() inline per recorder. .dictation redials faster and gives up sooner — a two-minute session with someone standing there is not a meeting.

MeetingRecorder moves onto both, so the gap is kept instead of dropped and the offset comes from the bridge.

DictationCoordinator gets reconnect at all: a dropped socket redials with the microphone still open, each leg gets its own id prefix so leg 2's first sentence cannot overwrite leg 1's, the tentative tail is folded into the settled text rather than dying with the socket, and only an exhausted ladder ends the session — keeping every word the keyboard already typed into the user's document.

Reconnecting no longer looks like failed, in both languages:

	reconnecting	live transcript over
meeting screen	amber spinner + "Transcription dropped — reconnecting…" / 「轉錄連線中斷，正在重新連線…」	full-weight ink + icon, "…the recording is still running and will be transcribed after it syncs."
dictation screen	"Reconnecting…" / 「重新連線中…」 with "keep talking, what you say is kept"	error state, "Lost the connection. What you already said has been typed…"
keyboard	amber "Reconnecting… keep talking" / 「重新連線中…可以繼續說」 above the transcript, which stays put	red error caption

The keyboard learns a reconnecting downlink state, so it stops going quiet mid-session. Red stays reserved for a session that actually ended; the meeting's "stopped" line is ink rather than red, because the recording is still running and colouring it like a failure would say the opposite of what the sentence says.

One failure is deliberately not retried. A 402 means the account is out of quota and the next handshake is refused identically, so SttRelayEvent.error now carries the relay's code and both paths say what happened instead of spending the whole ladder to arrive at "lost the connection".

Verified

• swift test --package-path ios/ParleyKit — 37 tests, 16 new: hold/flush ordering, the bound and its drop-oldest, timestamp continuity across a simulated reconnect leg (10 s of meeting + 3 s into the gap ⇒ the new leg is offset to 10 000 ms, not 13 000), discard-keeps-the-clock, a concurrent-sender test that no chunk is lost or reordered while a leg is swapped underneath, the backoff ladder and ceiling, and the quota code the parser and the event have to agree on.
• xcodebuild -project ios/App/Parley.xcodeproj -scheme Parley -destination 'generic/platform=iOS Simulator' CODE_SIGNING_ALLOWED=NO build — clean (after xcodegen generate).
• bunx tsc --noEmit and bunx vitest run (231 tests) — clean. Untouched by this change; run because CLAUDE.md asks for it.
• Every new string has both en and zh-Hant entries in the app and keyboard catalogs.

Not verified — needs a device

None of the below is reachable from a simulator or a unit test, and I have not run any of it. From the checklist in #283, for iOS:

• Incoming call, answered, then ended → recording continues, transcript continues, no gap beyond the call.
• Incoming call, declined → same.
• Wi-Fi → cellular handover mid-recording.
• Airplane mode for ~10 s mid-recording → reconnects, and the words spoken during the gap actually arrive (they are inside the 45 s hold, so they should — this is the specific claim most worth checking).
• Siri, an alarm, and another app opening a recording session.
• The relay restarted under a live session.
• The same six against dictation, where the ladder is shorter (0.5, 1, 2, 4 s) and the session is capped at two minutes — including that the keyboard shows "Reconnecting… keep talking" rather than going quiet, and that nothing is double-inserted across a leg change.
• A held gap longer than the bound (>45 s meeting / >20 s dictation) → the oldest audio is dropped and the surviving audio still lands at the right timestamp.

Two behaviours worth a specific eye on a device: the relay-side timestamps of a reconnected leg (the unit test proves the offset the client is given, not what the relay does with it), and whether a 402 arrives as an in-band error frame (handled) or as a socket close with code 1011 (falls through to the ordinary reconnect ladder, ending in the honest "live transcription stopped" line 75 s later).

Not in this PR

Android — no audio focus handling at all, and MeetingSession throws the reconnect gap away exactly as iOS did. It is a separate PR by someone who can build it: there is no Android SDK on the machine this was written on and CI skips android/** on pull requests, so shipping unbuildable Kotlin here would have been worse than not shipping it. Filed with the full design and the device checklist as #284.

Closes nothing on its own — #283 stays open until #284 lands.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud