NetherNet: SDP answers without ICE candidates until BDS restart

 Short description of the issue
     On a dedicated server running BDS 1.26.52.3 with transport=nethernet, after some client churn the HTTP signaling endpoint keeps answering POST /v1/join/{clientNetworkId} with HTTP 200 and an SDP answer that contains no
     ICE candidates. ICE stays "checking" and DTLS stays "new", so no client can complete a connection (community signalling code: CONNECTERROR 9, InactivityTimeout). The state persists for hours and clears only after
     restarting bedrock_server.

     Steps to reproduce the issue
     1. Start BDS 1.26.52.3 with transport=nethernet.
     2. Connect a client that follows the NetherNet HTTP signaling guide: GET /v1/join, then POST /v1/join/{clientNetworkId} with a full SDP offer.
     3. Disconnect and reconnect repeatedly, including switching between two client implementations for the same account and/or terminating a client process abruptly.
     4. At some point the POST keeps returning 200 while the SDP answer contains no a=candidate lines.

     Expected result
     SDP answers must always include complete ICE candidates ("full ICE", as required by the NetherNet HTTP Signaling onboarding guide). After previous sessions end, new negotiations should succeed and clients should connect.

     Actual result
     - POST /v1/join/{networkId} -> HTTP 200 application/sdp with an answer without any a=candidate lines; ICE stays checking.
     - The condition persists for hours of retries with players: 0; GET /v1/join keeps returning 200 and the console logs no connection attempt.
     - Only restarting bedrock_server clears the state; after the restart answers include candidates and connections succeed immediately.
     - BDS console: no error and no player connect/disconnect event during the failed attempts.


     Additional notes
     - Related reports: BDS-23108 (candidate-gathering analysis and single server-udp-ports mapping behavior), MCPE-242736.
     - Working hypothesis: a per-session UDP socket is not released, so no usable candidate can be allocated while server-udp-ports is a single port.
     - Attachments (probe output with candidate counts before/after restart, ss -uanp) can be provided on request or added later.