iOS: failed engine restart after AVAudioEngineConfigurationChangeNotification is silently dropped, audio dead until manual rebuild

Description

When iOS posts AVAudioEngineConfigurationChangeNotification (a Bluetooth A2DP route renegotiation around screen lock is a reliable trigger), SystemNotificationManager's handleEngineConfigurationChange stops the engine, rebuilds the graph, and calls start again. If the app is locked with an input node attached, iOS refuses that restart, and the failure is just dropped: no retry, no error surfaced to JS. The engine stays dead after that, so recording, playback, and any keepalive source all go silent until the consumer tears the whole pipeline down and rebuilds it (we do this after the phone unlocks).

Whether it reproduces depends on whether the notification fires while a session is active, so identical test rounds pass or fail nondeterministically, which made this painful to pin down.

What we were hoping for: a failed config-change restart gets retried at the next opportunity (foreground, unlock, next route change), or at least surfaces to JS so the app can react. Right now the only signal is that audio stops.

Steps to reproduce

1. iOS app with an active playAndRecord session, an AudioRecorder recording, and an engine rendering output, with Bluetooth earphones connected.
2. Lock the phone mid-session with audio still running.
3. Wait for the route renegotiation (A2DP tends to do this around lock, but it is timing luck; several rounds may be needed).
4. When it fires while locked, the engine dies: no input, no output, no error. Unlock and the app has to rebuild everything itself.

Snack or a link to a repository

This is from a production voice app I can't share a runnable repro of, sorry. The failing path is readable in SystemNotificationManager.mm (handleEngineConfigurationChange: stop, rebuild, start, with the start failure unhandled). Happy to share device traces from our failing rounds if useful: we see Failed to start audio engine with session active and a route change reason=ConfigurationChange right after, zero interruption events.

React Native Audio API version

0.13.2

React Native version

0.86.0

Platforms

iOS

Start in SystemNotificationManager.mm at handleEngineConfigurationChange and trace the stop, graph rebuild, and engine start path. Reproduce with an active playAndRecord session, recording, rendered output, and Bluetooth earphones while locking the iOS device. Done means a failed restart is retried at a later opportunity or surfaced to JavaScript, with audio no longer remaining silently dead.