fix(windows): prefer direct Codex executable launch over Store activation

[allenlhz01-pixel]

Problem

On Windows, Cockpit starts the default Codex app through the Store/AppUserModelId entry:

Start-Process shell:AppsFolder\\<AppUserModelId>

Windows brokers this launch through Explorer, so the resulting ChatGPT.exe process reports explorer.exe as its parent process even when Cockpit Tools initiated the launch.

This causes external process checks to incorrectly report that Codex was not started by Cockpit Tools.

Root Cause

The Windows default Codex startup path always tries Store/AppUserModelId activation before the configured executable path.

Solution

This PR changes the Windows default startup order:

1. Resolve the configured Codex executable path.
2. Start ChatGPT.exe directly from Cockpit Tools.
3. Preserve existing proxy environment variables, detached-process flags, and extra arguments.
4. Fall back to Store/AppUserModelId activation if the executable path is unavailable or direct startup fails.
5. Log the selected strategy as direct-exe or system-store-entry.

Direct startup keeps the Cockpit Tools -> Codex process relationship observable while preserving Store compatibility as a fallback.

Compatibility

• macOS behavior is unchanged.
• Managed Codex instance startup is unchanged.
• Account injection, proxy configuration, extra arguments, and PID tracking are preserved.
• Store/AppUserModelId activation remains available as a fallback.

Verification

• npm run build passed.
• Rust formatting check passed.
• Manual reproduction on Windows 1.3.24 confirms the issue: the current release still selects system-store-entry and the launched ChatGPT.exe has Explorer as its parent.
• Full Windows Tauri packaging requires the MSVC linker (link.exe).