p#682 Fix shutdown crash and cut WebRTC teardown time

terminate() released the thread unique_ptrs on the timeout path while the
detached shutdown thread was still running the lambda that reads them, so a
slow shutdown became a null deref at the next BlockingCall.  Leave the members
alone and report the timeout instead, so the caller leaks this object rather
than deleting it out from under the detached thread.

Reduce how often that timeout is reached at all:

- Post the audio device stop instead of blocking on it.  StopRecording and
  StopPlayout each wait up to 2s on a WASAPI thread, spending much of the 10s
  budget before the connections were touched.  The device stop has to stay on
  the worker thread (AudioDeviceBuffer is guarded by a sequence checker bound
  to it), but the queue is FIFO, so ForceTerminate still runs after it while
  the signaling close gets on with its network-thread work.

- Drain the peer connections in LLWebRTCVoiceClient::terminate() before handing
  off to llwebrtc::terminate(), bounded to 3s.  An estate session can hold ten
  live connections -- the current region plus up to eight neighbours -- and
  closing them inline and serially under the shutdown budget is what made it
  tight.  Draining also quiets the stats poll, so PeerConnection::Close() no
  longer blocks in WaitForPendingRequest() on an in-flight GetStats.

Connections reaped by the drain are destroyed while webrtc is still fully
alive, so they must unregister and release their peer connections normally;
key the destructor's early-out off a new sWebRTCTerminated instead of
isShuttingDown().  Notify signaling observers even when there was no peer
connection to close, or a connection shut down before it finished initializing
parks in VOICE_STATE_WAIT_FOR_CLOSE, which has no timeout of its own.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions