eframe on Windows opens restored when with_inner_size is combined with with_maximized(true)

### Description

On Windows, an `eframe` window configured with both `ViewportBuilder::with_inner_size(...)` and `ViewportBuilder::with_maximized(true)` can report a maximized Win32 state while the actual window rectangle remains at the restored/inner-size dimensions. Visually, the application opens restored instead of maximized.

This was found while debugging a mixed-DPI Windows issue in an `eframe 0.29.1` desktop app. Raw `winit 0.30.13` maximizes correctly with equivalent `WindowAttributes`; the issue appears in the `eframe` path.

### Minimal repro

```rust
use eframe::egui;

struct App;

impl eframe::App for App {
fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) {
egui::CentralPanel::default().show(ctx, |ui| {
ui.heading("eframe maximize repro");
});
}
}

fn main() -> eframe::Result<()> {
let options = eframe::NativeOptions {
viewport: egui::ViewportBuilder::default()
.with_title("repro_eframe")
.with_inner_size([1000.0, 650.0])
.with_maximized(true),
persist_window: false,
..Default::default()
};

eframe::run_native("repro_eframe", options, Box::new(|_cc| Ok(Box::new(App))))
}
```

The binary used a PerMonitorV2 manifest, but the maximization issue also appears independently of the mixed-DPI drag problem.

### Observed result

Win32 measurement after startup:

```text
Rect: (-9,-9)-(1259,851)
Size: 1268x860
ShowCmd: 3
Normal: (32,32)-(1300,892)
```

`ShowCmd == 3` means Win32 reports the window as maximized, but the actual rectangle is the restored-size rectangle. On a 1920x1080 primary monitor this is visibly not maximized.

Sending `ctx.send_viewport_cmd(egui::ViewportCommand::Maximized(true))` once from `App::update()` did not correct the rectangle.

### Workaround

Do not set an initial inner size when requesting maximized startup. Use `with_min_inner_size(...)` instead:

```rust
let options = eframe::NativeOptions {
viewport: egui::ViewportBuilder::default()
.with_title("repro_eframe")
.with_min_inner_size([1000.0, 650.0])
.with_maximized(true),
persist_window: false,
..Default::default()
};
```

Observed with the workaround:

```text
Rect: (-9,-9)-(1929,1029)
Size: 1938x1038
ShowCmd: 3
Normal: (32,32)-(1300,892)
```

This opens visually maximized.

### Comparison with raw winit

A raw `winit 0.30.13` app using:

```rust
WindowAttributes::default()
.with_title("repro_winit")
.with_inner_size(LogicalSize::new(1000.0, 650.0))
.with_maximized(true)
```

opens maximized correctly on the same machine.

### Platform

- Windows 11 24H2
- eframe 0.29.1
- egui 0.29.1
- winit 0.30.13
- Primary monitor: 1920x1080 at 125% scale
- Also tested in a 3-monitor mixed-DPI layout

Start at eframe::run_native and trace how NativeOptions.viewport is converted into the native window attributes and startup state on Windows. Compare that path with the raw winit WindowAttributes example, focusing on the interaction between with_inner_size and with_maximized(true). Done means the same eframe configuration opens with its actual rectangle maximized while retaining the requested inner size.

Written by the indexing model from the issue text.