[epic] Recovery implemented twice, neither re-runs signalling

[ctoth]

Root cause: recovery is implemented twice, at two layers, and neither re-runs signalling

Connection recovery exists in both WebRTCService.attemptRecovery (src/WebRTCService.ts:159) and FileTransferManager.attemptRecovery (src/FileTransferManager.ts:621). Neither knows about the other, and neither re-runs the offer/answer through the GMCP signalling channel, so a "recovered" peer connection has no remote description and can never reach connected.

Instances already filed

• WebRTC recovery rebuilds connection without re-signalling; dead connection + concurrent recoveries #72 WebRTC recovery rebuilds the connection without re-signalling; dual-triggered concurrent recoveries
• createPeerConnection leaks previous RTCPeerConnection/data channel on recovery path #73 createPeerConnection leaks the previous connection on the recovery path
• Outgoing file transfers time out after 30s (timestamp never refreshed) #61 outgoing-transfer timeout loop (compounded by the above)

Suggested direction

One recovery owner — the layer that holds the signalling channel (FileTransferManager) — drives re-negotiation; WebRTCService only reports transport state. Guard against concurrent recovery attempts.