[Bug][WebRTC] Sequential TC-WEBRTC tests lose video preview because /ws/video rebinds UDP port 5000

[xuzh-reolink]

Describe the bug

Test Harness version

• TH: v2.15+spring2026
• Platform: Raspberry Pi / Ubuntu 24.04
• Tests: TC-WEBRTC-1.1, TC-WEBRTC-1.2 and TC-WEBRTC-1.3

Description

Each TC-WEBRTC test displays video correctly when executed individually.

When multiple WebRTC test cases are executed sequentially, for example:

1. TC-WEBRTC-1.1
2. TC-WEBRTC-1.2
3. TC-WEBRTC-1.3

a later test intermittently fails to display video.

Observed behavior

• The DUT continues sending RTP packets.
• UDP packets are present on localhost port 5000.
• H.264 extracted from the packet capture can be decoded successfully with FFmpeg.
• The browser opens /api/v1/ws/video, but receives no binary video messages.
• Running the same failing test individually displays video correctly.

The backend reports:

ERROR | app.socket_connection_manager:relay_video_frames | Failed with [Errno 98] Address already in use

### Steps to reproduce the behavior

Start a WebRTC test run containing TC-WEBRTC-1.1, 1.2 and 1.3.
Complete the preview step in TC-WEBRTC-1.1.
Continue immediately to TC-WEBRTC-1.2.
Observe that the new /api/v1/ws/video connection opens, but no video is displayed.
Check the backend container logs.

### Expected behavior

The previous video relay and its UDP socket should be fully stopped before a new VIDEO WebSocket starts receiving frames.
Sequential TC-WEBRTC tests should display video as reliably as individually executed tests.

### Log files

_No response_

### PICS file

_No response_

### Screenshots

_No response_

### Environment

_No response_

### Additional Information

Use a single long-lived UDP receiver and relay frames to the current VIDEO WebSocket, or serialize VIDEO relay replacement so that:
1. The previous VIDEO WebSocket is closed.
2. The previous UDP socket is closed.
3. Only then may the new relay bind UDP port 5000.
The cleanup should close the UDP socket before awaiting WebSocket shutdown.
Using only SO_REUSEADDR is not sufficient because multiple receivers could compete for the same UDP datagrams.