Fix Windows MCP startup with silent stdin

[c64cryptoboy]

Summary

Fixes Windows GUI startup hanging when --mcp-server is launched with an open but silent stdin pipe. The window should appear without requiring the MCP client to send a message first.

The early MCP reader can block in stdin before VICE calls _setmode. That later call can wait on the CRT descriptor lock held by the read, preventing startup from progressing until input arrives.

Change

Initialize stdin/stdout binary mode at the beginning of Windows MT_PreInit, before starting the MCP reader. Use InitOnceExecuteOnce so VICE reuses that initialization instead of repeating _setmode.

This keeps MCP startup early: no sleeps, emulator-readiness waits, or parser/backend changes. _fmode stays at its original initialization point; stderr and non-Windows startup are unchanged. Binary stdio now applies earlier to other Windows startup paths too, including redirected help/version output.

Reproduction

1. On Windows, launch c64d.exe --mcp-server from the normal application working directory with stdin/stdout/stderr redirected. Keep stdin open and drain both output streams, but send no input for 30 seconds. Use a fresh MT_SETTINGS_DIR to avoid changing normal settings.
2. Before this fix, no visible application window appears during that interval.
3. Send a newline-terminated notification, for example {"jsonrpc":"2.0","method":"retro_headful_unknown_notification_probe","params":{}}. Startup resumes and the window appears.
4. With the fix, the GUI appears and responds while stdin is still silent.

Launching from an ordinary console or immediately sending initialize can hide the problem.

Validation

Matched native MSVC x64 Debug builds, using the same engine revision and build options:

Check	Before	After
Startup stalls during five 30-second silent-input trials	5/5	0/5
GUI responsive before input	0/5	5/5
Valid initialize responses after observation/wake	5/5	5/5

The fixed GUI responded in 3.1–3.3 seconds. All five visible MCP instances and the normal-GUI control exited normally. Separate native helper tests passed across /MD and /MT, covering legacy/fixed ordering, concurrent initialization and byte preservation.

Headless initialize also passed; headless cleanup was forced in both control and candidate. One earlier normal-GUI harness run was inconclusive after reporting a zero-size window; the subsequent focused diagnostic and full comparison passed, and that earlier observation remains unexplained.

The PR contains only the three-file startup fix, separate from the MSVC build-compatibility changes used for local testing. Linux/macOS/Windows CI remains to be checked for this PR; initialize-at-launch timing and live bridge/menu operation were reviewed statically, not separately exercised.