fix(windows): prevent startup window freezes

[vicente-higino]

Pull Request Description

Fixes Windows startup races that could leave Fladder frozen on the logo, transparent, invisible, or incorrectly restored after an external window manager changed its startup state.

Root cause

• Windows startup performed blocking taskbar/window operations while the first Flutter frame was being attached.
• The native runner did not reliably reveal and resize the hosted FLUTTERVIEW after FancyZones or another program moved/maximized the top-level window.
• Player and Windows system-media-control initialization could overlap during startup and create a large native thread workload before the UI became interactive.
• Startup move/resize events could overwrite saved normal bounds or undo externally requested placement.

Changes

• Let the native Windows runner own the initial show and preserve the launcher show command.
• Explicitly show and resize the hosted Flutter child on the first frame.
• Avoid the blocking Windows taskbar visibility call and transparent startup path.
• Preserve externally maximized, fullscreen, or FancyZones-managed placement.
• Ignore transient startup placement events and avoid persisting maximized/fullscreen bounds.
• Initialize the player lazily on Windows and make player/SMTC initialization single-flight and retryable.
• Add focused regression tests for window policy and initialization concurrency.

Issue Being Fixed

Resolves #1001

Related to #859 and microsoft/PowerToys#32655.

Screenshots / Recordings

N/A. The fix was validated with repeated HWND/FLUTTERVIEW visibility and responsiveness probes under the active FancyZones configuration.

Tested On

• Android Phone
• Android Tablet
• Android TV
• iOS
• macOS
• Windows
• Linux

Validation

• dart format --output=none --set-exit-if-changed --line-length 120 on all changed Dart source files: clean.
• flutter analyze: no issues.
• 12 focused window/player/single-flight tests: all pass.
• Windows release native runner and Dart AOT payload compile successfully with Flutter 3.35.7.
• 6/6 normal FancyZones-managed launches remained rendered and responsive.
• 5/5 launcher-requested maximized launches preserved maximization.
• 5/5 immediate external-maximize launches preserved maximization and a visible Flutter child.
• Full suite: 21 tests pass; one unrelated pre-existing obsolete counter widget test still fails because it lacks the application ProviderScope.

AI Assistance Disclosure

This fix was developed with assistance from OpenAI Codex. Codex was used to inspect the startup and native-window paths, correlate local behavior with the linked GitHub reports, implement and refine the changes, generate focused regression tests, run repeated builds and runtime probes, and prepare this pull request. The contributor directed the investigation and manually confirmed the installed Windows build behaves correctly.

Approximately three hours of active AI-assisted investigation, implementation, and validation went into the fix before PR follow-up work. The extended investigation was necessary because the visible freeze was caused by multiple interacting startup races across Dart initialization, Windows player/SMTC setup, the native Win32 host and hosted FLUTTERVIEW, and external window placement by FancyZones/PowerToys. Process responsiveness alone initially produced a false positive, so repeated HWND/child-visibility inspection, native/AOT rebuilds, and normal/maximized launch stress tests were needed to isolate and verify the fix.

Checklist

• No unrelated package or generated-file changes are included.
• Focused tests cover the affected behavior.
• Existing macOS, Linux, Android, and web eager player initialization behavior is preserved.
• The change was tested in a Windows release build.