fix(windows): defer startup window restoration

[vicente-higino]

Summary

Follow-up to #1069 that focuses the window-related portion of the Windows startup issue.

Windows window-manager calls are now deferred until the native window and external placement tools have had 750 ms to settle. Stored bounds are restored only when the window still has the runner's native startup bounds and is neither maximized nor fullscreen.

The native runner changes are limited to keeping the hosted FLUTTERVIEW visible and ensuring WM_SIZE always reaches the child-resize path.

Relates to #1001.

Changes

• Defer Windows background, title-bar, title, HTPC-mode, and stored-bounds calls until after startup settles.
• Automatically detect externally managed placement; no user setting is required.
• Preserve maximized, fullscreen, and FancyZones-managed bounds.
• Ignore startup move/resize persistence for 2.5 seconds and avoid saving maximized/fullscreen geometry.
• Explicitly show the hosted Flutter child during attachment.
• Forward WM_SIZE through the runner even when a plugin reports the message as handled.
• Add focused window-policy regression tests.

Impact

Normal saved window bounds still restore when no external manager changes startup placement. External placement is preserved instead of immediately being overwritten.

Some external managers use monitor-sized normal bounds instead of Windows' formal maximized state. This change intentionally preserves those external bounds rather than forcing a maximize command.

Validation

• Dart formatting at the repository's 120-column width: clean.
• flutter test --no-pub test\window_helper_test.dart: 5/5 pass.
• flutter analyze --no-pub: no issues.
• Windows release build succeeds with Flutter 3.35.7.
• The window-only diagnostic build kept the Flutter child visible in 10/10 normal and early-maximize launches.
• In the final combined diagnostic build, all 50 launches remained visible and responsive; 30/30 normal launches passed the full probe.
• Contributor manually tested the Windows build with PowerToys/FancyZones.

AI Assistance Disclosure

This change was developed with assistance from OpenAI Codex. Codex was used to inspect the Dart and Win32 startup paths, correlate the behavior with #1001 and #1069, implement the automatic placement detection, add tests, build the Windows release, and run repeated HWND/FLUTTERVIEW probes.

Approximately three hours of active AI-assisted investigation, implementation, and validation went into the window portion, plus several days of intermittent manual testing by the contributor. The extended investigation was needed because a responsive top-level HWND could still contain an invisible Flutter child, and external window placement raced with both first-frame attachment and saved-bounds restoration.