Right secondary display is dropped when shrinking the primary display

When using NVIDIA rendering and WebRTC on Wayland, reducing the primary display from **1920×1080 to 1280×720** causes the right-hand secondary display to be dropped.

The server attempts to recreate the secondary at its new position while the primary still occupies its previous rectangle, resulting in an overlap rejection.

## Steps to reproduce

1. Start a Wayland session using NVIDIA/GLES2, NVENC H.264 and WebRTC.
2. Set the primary display to manual **1920×1080**.
3. Add a secondary display **on the right** and wait for its stream to connect.
4. Keep the secondary open.
5. Change the primary display’s manual resolution to **1280×720**.

## Expected behavior

The primary resizes, the secondary moves next to its new right edge, and both displays remain usable.

## Actual behavior

The secondary is dropped. Server logs:

```text
INFO:webrtc:Wayland output 2 moves to +1280+0; recreating it.
[Wayland] CreateOutput 2: rejected, logical rect 1280x720+1280+0 overlaps output 0 at 1920x1080+0+0.
ERROR:webrtc:Secondary display 'display2' dropped on Wayland: The compositor cannot create an output for this display.
```

The same session also failed during an automatic viewport/DPR reduction. The manual reproduction above demonstrates that an automatic browser resize is not required.

## Confirmed environment

- Chrome on macOS.
- Open OnDemand / Apptainer, nested Wayland session.
- NVIDIA/GLES2 rendering, NVENC H.264, WebRTC.
- Desktop-Wayland app **0.9.0**, image **0.10.0**, base **0.6.5**.
- Selkies: `07862a15868a1047817e039eb5641a4c0cce285f`
- PixelFlux: `aa3679cf3b835ecd1e4b1a1d6aa8c84727c0af66`
- PCMFlux: `ee52090e1a53e638455e203f87c7a95040035ac7`
- No downstream patches to these components.

## Additional observations

The same resolution change succeeded with CPU/Pixman and WebSocket. Since both hardware and transport differed, this comparison does not isolate WebRTC as the sole cause.

The previously observed HiDPI gap did not reproduce with this tuple. This report concerns losing the secondary during a primary-resolution reduction.

## Possible cause — not confirmed

In `src/selkies/webrtc_mode.py`, `WebRTCService._apply_wayland_extension` recreates a secondary when its origin changes. The observed logs suggest that this recreation happens before the primary has finished shrinking.

Could the resize ordering leave the old primary rectangle active when the secondary is recreated?

Start in src/selkies/webrtc_mode.py at WebRTCService._apply_wayland_extension, then trace the Wayland output recreation and resize ordering shown by the logs. Reproduce the manual primary-display reduction with the confirmed NVIDIA/GLES2, NVENC H.264 and WebRTC setup. Done means shrinking the primary moves the secondary beside its new right edge without dropping it or triggering an overlap rejection.

Written by the indexing model from the issue text.