Different Msaa on two separate cameras crashes at runtime

Using two cameras, each with a distinct `Msaa` setting, will crash at startup.
The fact that Msaa can be added as a Component to each camera implies that it should be customizable per camera.

## Bevy version and features

- Bevy 0.19.1
From the Lockfile:
```
[[package]]
name = "bevy"
version = "0.19.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4bfadbebfc6599aa59289b754ac30023959854304f3d393da2cf62bb3cd5df8f"
dependencies = [
"bevy_dylib",
"bevy_internal",
]
```

I will attach the full reproduction project.

## \[Optional\] Relevant system information

Rust Version
```
cargo --version
cargo 1.98.0-nightly (a595d0da2 2026-06-20)
```

OS Version:
```
uname -a
Linux nevermore 6.12.94+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.94-1 (2026-06-20) x86_64 GNU/Linux
generic@nevermore:~/projects/games/bevy-repros/tinystars$
```
This is Debian Trixie with KDE on Wayland.

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

```
`AdapterInfo { name: "Intel(R) Graphics (MTL)", vendor: 32902, device: 32069, device_type: IntegratedGpu, device_pci_bus_id: "0000:00:02.0", driver: "Intel open-source Mesa driver", driver_info: "Mesa 25.0.7-2+deb13u1", backend: Vulkan, subgroup_min_size: 8, subgroup_max_size: 32, transient_saves_memory: false }`
```

## What you did

Have two cameras like so:

```rust
use bevy::prelude::*;

fn main() {
let mut app = App::new();
app.add_plugins((
DefaultPlugins,
))
.add_systems(Startup, setup_camera);
app.run();
}

fn setup_camera(mut commands: Commands) {
let camera = (
Camera2d,
Msaa::Sample8,
Camera {
order: 90, // just to avoid having the same order on both cameras
..default()
},
);

commands.spawn(
camera,
);

let camera2 = (
Camera2d,
Msaa::Sample4,
);
commands.spawn(camera2);
}

```

Then `cargo run` and watch it crash.

## What went wrong

```
2026-08-21T18:16:28.064965Z INFO bevy_pbr::cluster: GPU clustering is supported on this device.
2026-08-21T18:16:28.065003Z INFO bevy_render::batching::gpu_preprocessing: GPU preprocessing is fully supported on this device.
2026-08-21T18:16:28.065470Z INFO bevy_winit::system: Creating new window tinystars (65v0)
2026-08-21T18:16:28.248661Z ERROR bevy_render::error_handler: Caught rendering error: Validation Error

Caused by:
In a CommandEncoder
In a pass parameter
Attachments have differing sample counts: the depth attachment's texture view has count 8 but is followed by the color attachment at index 0's texture view which has count 4

2026-08-21T18:16:28.249390Z ERROR bevy_render::error_handler: Caught rendering error: Validation Error

Caused by:
In Queue::submit
In a pass parameter
Attachments have differing sample counts: the depth attachment's texture view has count 8 but is followed by the color attachment at index 0's texture view which has count 4

2026-08-21T18:16:28.254519Z ERROR bevy_render::error_handler: Quitting the application due to Validation RenderError
```

## Additional information

This happens because there are both `Msaa::Sample8` and `Msaa::Sample4` in use. When both cameras use the same setting, it works as expected.

The context why I ran into this is less relevant, but I'll include it anyway: I was trying to figure out how to reliably show tiny entities in the background. With default Msaa settings (`Sample4`) they flicker out of existence. With `Sample8` they still flicker, but acceptably so. I thought it doesn't make sense to also make the camera for my UI use increased sampling because I don't need it there. Tbh I did not even realize this could be an issue until I ran the program.

I will attach the full reproduction example project, but the above `main.rs` snippet should suffice.
[tinystars.zip](https://github.com/user-attachments/files/31316802/tinystars.zip)

Start with the minimal main.rs reproduction in the issue and run it with two cameras using Msaa::Sample8 and Msaa::Sample4. Trace the camera MSAA and render attachment handling to find why the depth and color attachments receive different sample counts. Done means distinct per-camera settings no longer cause a render validation error or application exit, with regression coverage for the reproduction.

Written by the indexing model from the issue text.