Windows: `restore_state` is accepted but ignored by the WebView2 host

Summary

On Windows, WindowOptions.restore_state is passed through the Zig platform layer to the native WebView2 host, but the host ignores it.

Both functions receive the value:

native_sdk_windows_create(..., int restore_frame, ...)
native_sdk_windows_create_window(..., int restore_frame, ...)

but immediately discard it:

(void)restore_frame;

Expected behavior

When restore_state = true, the Windows host should restore the previous window frame and maximized state.

When restore_state = false, the window should open using the explicitly declared frame and should not restore persisted state.

Actual behavior

restore_state has no effect on Windows. The host does not persist or restore the window frame.

Why this matters

Applications commonly need both behaviors:

• onboarding/setup windows should always open at a fixed, known size;
• the main application window should reopen at the user’s previous size and maximized state.

The option is already exposed by the public API, but its Windows WebView2 implementation currently does not honor it.

Environment

• Native SDK: v0.7.1
• Platform: Windows x64
• Web engine: system / WebView2
• Zig: 0.16.0

Start at the Windows WebView2 host implementations of native_sdk_windows_create and native_sdk_windows_create_window, following restore_frame to the points where it is discarded. Check how window frames and maximized state are persisted or restored. Done means restore_state=true reopens the saved frame and maximized state, while false uses the declared frame without restoring persisted state.