windows: the app spawn sets no CREATE_NO_WINDOW, so a console-subsystem launch can flash a console window that takes foreground

[xxx]

The Windows app spawn sets CREATE_SUSPENDED and nothing else
(crates/glass-windows/src/process.rs:349), so a console-subsystem launch can put a console window
on screen and take foreground.

CREATE_SUSPENDED is correct and load-bearing — the process must be suspended so it can be
assigned to the Job object before it runs. The gap is that no CREATE_NO_WINDOW accompanies it.

We already know this console exists. find_app_window's rung-1 documentation
(crates/glass-windows/src/windows.rs) calls it out by name:

under Sandboxie only the boxed app's Sandbox:<box>:-renamed windows qualify, so glass's own
launcher console — which Sandboxie leaves as ConsoleWindowClass — is skipped

Skipping it during discovery keeps it from being adopted as the app's window. It does not keep
it from appearing, and it does not keep it from taking the foreground — which matters because
synthetic input goes to whatever holds focus.

Impact

A launch like ["python", "app.py"] is console-subsystem. The console appears, and any input sent
before the app's own window is focused can land in the wrong place. A GUI-subsystem binary is
unaffected.

Status

Theoretical. Read from the spawn flags and the rung-1 comment; not reproduced. Confirming it
needs an interactive Windows desktop session and a console-subsystem launch.

Fix direction

Add CREATE_NO_WINDOW to the creation flags. It suppresses the console window without affecting
the stdout/stderr pipes glass_logs reads, so log capture is unchanged.