Bevy slows down to <1FPS when a non-mailbox-vsync window is not ""visible""

## Bevy version and features

- The release number or commit hash of the version you're using: `0.19.1` or `396ca727080776bd313bb892423b7d94e03b81b4`
- If you're not using default features, the combination of bevy's cargo features you are using: `bevy_dev_tools`

## \[Optional\] Relevant system information

OS: NixOS Latest unstable as of today, **COSMIC** DE.

If your bug is rendering-related, copy the adapter info that appears when you run Bevy.

```ignore
AdapterInfo { name: "AMD Radeon RX 6800 (RADV NAVI21)", vendor: 4098, device: 29631, device_type: DiscreteGpu, device_pci_bus_id: "0000:03:00.0", driver: "radv", driver_info: "Mesa 26.2.1", backend: Vulkan, subgroup_min_size: 32, subgroup_max_size: 64, transient_saves_memory: Some(false), limit_bucket: None }
```

You should also consider testing the examples of our upstream dependencies to help isolate any setup-specific issue:

- [`wgpu`](https://github.com/gfx-rs/wgpu) for rendering problems: unaffected, i used a modified version of the `02_hello_window` example.
- [`winit`](https://github.com/rust-windowing/winit) for input and window management: used by the wgpu test.
- [`gilrs`](https://docs.rs/gilrs/latest/gilrs/) for gamepad inputs: unrelated, i don't have a gamepade connected.

## What you did

When I was developing a multi-window app some of my windows would get covered up by other windows in a stack, I tested moving windows to a different desktop and that also causes the same issue.
(and none of the windows used mailbox vsync as bevy doesn't default to it and i didn't know to check vsync)

## What went wrong

whenever a non-mailbox-vsync window was in a window stack, but a different window in the stack is active, or on another desktop environment all visible windows slowed down to <1fps.

(all windows in the video use FIFO)
https://github.com/user-attachments/assets/0a3bc5f8-ea84-4e96-b9ec-ed8e24e4af6c

## Additional information

Other information that can be used to further reproduce or isolate the problem.
This commonly includes:

- screenshots
- logs
- theories about what might be going wrong:
my theory is COSMIC slows down all windows it knows are never going to be visible to 1FPS as a optimization,
most apps work as expected with this as they never wait for all windows to be ready before rendering, they just render the slow window at a slower pace while letting the fast windows render quickly.

bevy blocks on ALL windows after every update, so bevy always runs at the pace of the slowest window, which is 1 FPS when COSMIC tries to reduce unneeded rendering work,
mailbox avoids the issue by letting bevy render as many frames as it wants, overwriting old frames if necesarry.
- workarounds that you used:
set DisplayMode (vsync) to mailbox (only the slow windows need to be on mailbox, the fast ones can use whatever vsync they want).

**NOTE**:
for some reason setting vsync to mailbox also works around https://github.com/bevyengine/bevy/issues/25491
- links to related bugs, PRs or discussions

Start by reproducing the multi-window case on Bevy 0.19.1 with FIFO versus mailbox, using the reported COSMIC/NixOS setup where possible; compare it with the unaffected modified wgpu 02_hello_window example. Trace the multi-window rendering path and verify that a covered or moved window no longer forces all windows below 1 FPS while retaining correct vsync behavior.

Written by the indexing model from the issue text.