fix(audio-response): make repeated operations reliable

[TobiasRoeddiger]

Summary

• prevent a delayed cancellation from an old BLE stream controller from removing a replacement subscription created after reconnect
• serialize overlapping audio-response requests so a rapid repeat waits for cleanup instead of failing with operation already in progress
• guard notification waits started before BLE writes so a failed write cannot later surface a detached status stream closed exception
• cover all three timing/error paths with regression tests

Root causes

A disconnected stream can finish closing after the app has already reconnected and installed a new controller for the same characteristic. The old onCancel callback checked only whether the key existed, so it removed the new controller and disabled its notifications.

Two related failure paths made this more visible during rapid Seal Check repetition:

1. Reopening the app while the prior request was finishing subscription cleanup caused the manager to reject the next operation instead of waiting.
2. The protocol intentionally starts waiting for a notification before issuing its corresponding BLE write. If that write failed, the pending wait was left detached and later emitted a second unhandled stream-closed error.

Validation

• flutter analyze
• flutter test (11/11)
• 20/20 rapid full hardware sessions with fresh tone uploads and immediate back/reopen/re-measure navigation
• 89/89 same-session hardware measurements (one initial upload plus 88 cached repeats) before the extended run was stopped at the user's request
• zero Android UniversalBle, Pigeon, write, timeout, detached-future, or operation-state errors attributable to the app in the passing runs
• tested against OpenEarable firmware PR #257 without resetting the phone bond

Companion firmware fix: OpenEarable/open-earable-2#257

[github-actions]

Visit the preview URL for this PR (updated for commit 845face):

https://open-earable-lib-web-example--pr144-codex-fix-ble-subs-69adpoxg.web.app

_{(expires Tue, 25 Aug 2026 07:27:25 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 7f6db4d9d00b851ad49af109fa949061904b3151}