Windows AutoNoVsync window can present black after resize until surface is reconfigured

## Bevy version and features

Bevy `0.18.1`.

Minimal repro uses:

```toml
bevy = { version = "=0.18.1", default-features = false, features = [
"std",
"async_executor",
"bevy_asset",
"bevy_camera",
"bevy_core_pipeline",
"bevy_image",
"bevy_log",
"bevy_mesh",
"bevy_render",
"bevy_sprite",
"bevy_sprite_render",
"bevy_text",
"bevy_ui",
"bevy_ui_render",
"bevy_winit",
"default_font",
"keyboard",
"mouse",
"png",
] }
```

## Relevant system information

Rust/Cargo:

```text
cargo 1.96.0 (30a34c682 2026-05-25)
rustc 1.96.0 (ac68faa20 2026-05-25)
host: x86_64-pc-windows-msvc
```

OS:

```text
Microsoft Windows [Version 10.0.26200.8655]
```

GPU from Windows registry:

```text
NVIDIA GeForce GTX 970
DriverVersion: 32.0.15.8129
```

Bevy adapter info:

```text
[paste AdapterInfo line here if available]
```

## What you did

I ran a Bevy 0.18.1 windowed 2D app using `PresentMode::AutoNoVsync`, then repeatedly resized the window.

Minimal repro: [bevy_resize_black_repro.zip](https://github.com/user-attachments/files/29106515/bevy_resize_black_repro.zip)

Run:

```powershell
cargo run --release
```

The repro logs resize events and includes a render-graph diagnostic node after `Node2d::Upscaling` that reports whether the final view target needs presentation.

The same repro has a workaround mode:

```powershell
cargo run --release -- --kick-present-mode
```

That briefly changes `Window.present_mode` from `AutoNoVsync` to `AutoVsync` after resize, then restores `AutoNoVsync` two frames later.

## What went wrong

Expected:

After resizing the window, the app should continue presenting the rendered frame normally.

Actual:

After resizing, the window sometimes becomes entirely black. The app continues running. In my original app this could black out the whole screen including UI/HUD. Minimizing and restoring the window fixes it. In the minimal repro, the issue is visible in the attached video.

The render diagnostics indicate that Bevy’s render graph continues to produce a valid resized output. After resize, the logs show:

```text
event="resize_event" ... present_mode=AutoNoVsync
event="post_upscale_present" ... needs_present=true ... physical_target_size=1920x1080 ... main_texture_size=1920x1080
```

There were no Bevy/wgpu surface warnings in the log.

## Additional information

Video: [attach video](https://github.com/user-attachments/assets/44b86ff6-b2aa-468e-8083-22f2aa1b9173)

Workaround:

Temporarily switching the wind

ow present mode to `AutoVsync` after resize, then restoring `AutoNoVsync`, appears to fix or prevent the black frame:

```text
AutoNoVsync -> AutoVsync -> AutoNoVsync
```

My theory is that a Windows/DXGI/wgpu surface can get stuck presenting a stale black frame after resize in `AutoNoVsync`, even though Bevy’s render graph reaches a view target with `needs_present=true`. Changing present mode forces Bevy/wgpu to reconfigure the surface, similar to the way minimize/restore recovers it.

Start by running the linked minimal repro with `cargo run --release` on Windows and compare `AutoNoVsync` behavior during repeated resizes with the `--kick-present-mode` workaround. Trace the window `present_mode`, the resize event, the render-graph point after `Node2d::Upscaling`, and surface reconfiguration. Done means resized frames continue presenting without requiring minimize/restore or a temporary present-mode change.

Written by the indexing model from the issue text.