Description
## Symptom
Stream connection fails at stage=10 (audio stream establishment) with errorCode=-1. The app immediately retries but the body is now BUSY; the resume attempt then fails at stage=4 (RTSP handshake) with errorCode=54 (ECONNRESET). The stream never connects.
## Log evidence
From issue #248 (bxl1-test/ad6, 2026-05-20 09:35):
```
09:35:10 [prev] [ObjC] ClStageFailed: stage=10 name=audio stream establishment errorCode=-1
09:35:10 [prev] Stream: failed after 0.9s -- Connection Failed: audio stream establishment failed with error -1
09:35:10 [prev] [ObjC] HydraStreamSession: stop() called -- sending /cancel + dismissing VC
09:35:10 [prev] Stream error: Connection Failed: audio stream establishment failed with error -1
09:35:10 [prev] [ObjC] StreamManager: serverinfo done -- state=SUNSHINE_SERVER_BUSY
09:35:10 [prev] [ObjC] StreamManager: server BUSY -- resuming app...
09:35:10 [prev] [ObjC] Connection: LiStartConnection returned -1 -- releasing initLock
09:35:10 [prev] [ObjC] Connection: initLock acquired -- calling LiStartConnection...
09:35:20 [prev] [ObjC] ClStageFailed: stage=4 name=RTSP handshake errorCode=54
09:35:20 [prev] [ObjC] Connection: LiStartConnection returned 54 -- releasing initLock
```
Also visible in issue #302 log (different session, same stage=10 errorCode=-1 pattern).
## Root cause hypothesis
stage=10 errorCode=-1 typically means the audio UDP port (48000) is unreachable or closed. The body may have launched the app successfully but the audio port was not ready in the 0.9s window. After the /cancel, the body stays BUSY and the resume RTSP handshake gets reset (errorCode=54) because the previous session cleanup is still in progress.
## Appears in
Issues #248, #302 (bxl1-test, fluffy-dumpling-87 / cosmic-pretzel-98, v0.2.87 era).
## Impact
User taps experience, sees brief connecting UI, then fails. The retry cascade also leaves the body in a BUSY state briefly.
## Notes
- Distinct from #245 (serverCodecModeSupport=0 pre-connection failure)
- The fix for #245 (v0.2.87) is visible in these logs (serverCodecModeSupport=2032385), so this is a different failure mode that survived the #245 fix