VS Code restores invalid window/maximize state on GNOME Wayland; XWayland works correctly

Does this issue occur when all extensions are disabled?: Yes

## Environment
```
VS Code: 1.131.0
Commit: e4c7e7b1d6d060162f4aa7f8225271b67ce1df75
Architecture: x64
OS: Ubuntu 22.04 LTS
GNOME Shell: 42.9
Kernel: 6.8.0-136-generic
Session: Wayland (XDG_SESSION_TYPE=wayland)
Multi-monitor system: laptop display + external display
```

## Problem

When VS Code starts natively under Wayland, its saved window state is not restored correctly.

VS Code was previously closed maximized on the secondary/external display.

On the next launch, it consistently:

Opens on the primary laptop display instead
Opens at approximately 60% of the screen size
Is positioned at the upper-left of the display
Shows a maximize button, but clicking Maximize does nothing
The maximize button acknowledges the click visually, but the window does not change

GNOME keyboard maximize initially behaves incorrectly as well.

For example:

- Press Super+Up → no effect
- Press Super+Down → no effect
- Press Super+Up again → window finally maximizes

After this sequence, the window behaves normally and remains maximized when switching between applications.

Another way to repair the already-running VS Code window is to toggle Ubuntu Dock between auto-hide and fixed. After changing the dock setting, VS Code behaves normally.

However, closing and restarting VS Code causes the invalid initial state to return.

## Steps to reproduce
- Use GNOME under a Wayland session with two displays.
- Place VS Code on the secondary display and maximize it.
- Close VS Code.
- Start VS Code normally.
- Observe that it opens approximately 60% size at the upper-left of the primary laptop display instead of maximized on the secondary display.
- Click the maximize button.
- Observe that the button reacts visually but the window does not maximize.
- Press Super+Up. It may also have no effect.
- Cycle Super+Down / Super+Up. The window eventually enters a valid maximized state.
- Switch repeatedly between VS Code and another application such as Chrome. Once repaired, VS Code remains maximized and behaves normally.
- Close and restart VS Code. The invalid initial state returns.

### XWayland comparison

Launching the same VS Code installation with:

```code --ozone-platform=x11```

completely resolves the problem.

Under XWayland, VS Code:

- Opens on the correct secondary display
- Opens maximized
- Correctly restores the previous window state
- Maximizes normally
- Remains maximized when switching between VS Code and Chrome
- Continues to restore correctly after closing and restarting VS Code

This was reproduced repeatedly.

My current workaround is:

```
Exec=/usr/share/code/code --disable-gpu --ozone-platform=x11 %F
Exec=/usr/share/code/code --disable-gpu --ozone-platform=x11 --new-window %F
```

### Ubuntu Dock isolation test

Ubuntu Dock was disabled completely:

```gnome-extensions disable ubuntu-dock@ubuntu.com```

After logout/login with Ubuntu Dock disabled, native-Wayland VS Code still reproduced the bad startup state:

- Opens on primary laptop display
- Approximately 60% size
- Upper-left position
- Non-functional maximize button

Therefore Ubuntu Dock does not appear to be the cause.

Changing the dock setting while VS Code is already running appears only to trigger a GNOME/Mutter window/work-area recalculation that repairs the invalid window state.

## Expected behavior

VS Code running natively under Wayland should restore the same monitor and maximized window state that it restores correctly when run through XWayland.

## Actual behavior

Native Wayland starts VS Code with an apparently inconsistent window state in which:

- Saved monitor placement is incorrect
- Saved maximized state is not restored
- Normal maximize initially fails
- GNOME/Mutter maximize commands initially fail
- Forcing a window-state/work-area transition repairs the running window

Since `--ozone-platform=x11` reliably eliminates all of these symptoms on the same GNOME session, VS Code configuration, extensions and hardware, the issue appears specific to the native Wayland/Electron window-state path.