[codex] Fix multiviewer stale elements on reconnect

[steveseguin]

Summary

Fixes the multiviewer reconnect path where a failed or ungraceful viewer teardown could leave UUID-named GStreamer elements in the shared pipeline. A later viewer using the same UUID could then create a new unparented element with the same name and fail to link against videotee/audiotee.

Changes

• Remove stale per-viewer webrtcbin, video queue, and audio queue elements by name before creating a new multiviewer peer.
• Track newly added multiviewer elements immediately after successful pipe.add() so disconnect cleanup can remove them even if a later link fails.
• Add a final multiviewer cleanup pass by element name during disconnect cleanup.

Validation

• Reproduced the underlying GStreamer name-collision behavior locally with WSL GStreamer 1.24.2.
• Live E2E via https://vdo.ninja/?password=false&view=<streamid> using publish.py --test --multiviewer --noaudio --vp8 --nored --password false:
  • 3 Chrome viewers joined concurrently.
  • 2 ungraceful viewer kills were detected by heartbeat timeout and cleaned up.
  • Same viewer profiles rejoined successfully after disconnect.
  • Publisher log showed 5 successful viewer connections, 2 cleanup stops, and 0 occurrences of the reported common ancestor / hasn't been added warning.
• python -m py_compile publish.py
• wsl python3 -m py_compile /mnt/c/Users/steve/Code/raspberry_ninja/publish.py
• pytest -q tests/test_config_loader.py tests/test_multiple_webrtc_connections.py tests/test_v4l2_device_retry.py with PYTHONPATH set to repo root: 14 passed.
• WSL import publish succeeded.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}