fix(coding-agent): Windows support for kernel bootstrap and console-less daemon spawns

[FiveTechSoft]

Summary

On Windows, prime-agent's daemon and session workers run console-less. Every child_process spawn from those processes makes Windows allocate a fresh console window, which users see as cmd windows flashing at startup, every ~15s (git footer/context polling), and on every agent tool call. Separately, the IPython kernel bootstrap hardcodes the POSIX venv interpreter path (bin/python), which doesn't exist in Windows venvs (Scripts/python.exe), so first-time setup on Windows deleted and rebuilt the kernel venv in an endless failure loop ("kernel is still bootstrapping... let me retry").

Changes

• Kernel bootstrap (core/kernel/bootstrap.ts): resolve the venv interpreter as Scripts/python.exe on Windows, bin/python on POSIX, via a new venvPythonPath() helper used by both bootstrapVenv() and ensureKernelPythonUncached().
• windowsHide sweep: add windowsHide: true to all background child_process call sites that can run inside console-less daemon/worker processes: git context/branch polling (utils/git.ts, footer-data-provider.ts), session-lease PowerShell queries, config and package-manager command probes, bash tool, exec.ts, autonomous runner, kernel/fork-server/bootstrap spawns, daemon catalog process, fd autocomplete search (packages/tui), session trash, gh share commands, tar/--version probes, clipboard helpers, rpc client. Interactive spawns (owned session worker with inherited stdio, external editors, self-update) and already-detached spawns (which get no console on Windows) are intentionally left untouched.
• Command recovery journal: tolerate directory fsync failures (Windows raises EPERM), matching the existing tolerant pattern in cron-jobs.ts — the atomic rename still protects readers. This was spamming EPERM: operation not permitted, fsync warnings on every journal compaction.

Testing

• Verified on Windows 11 (Windows Terminal): before the fix, process monitoring captured each background git.exe spawn creating a new conhost.exe + OpenConsole.exe pair (the visible flashes); after the fix, none are created.
• Kernel bootstrap now completes on Windows: venv created with ipykernel, prime-agent-runtime, dill and default packages import correctly.
• biome check, tsgo --noEmit, installer and browser-smoke pre-commit checks all pass.
• Note: some tests in test/kernel-bootstrap.test.ts, test/session-lease.test.ts and test/ipython-provisioner.test.ts fail on Windows, but they fail identically on the pristine tree (they use POSIX shell-script fake executables) — pre-existing, not caused by this change.

Note

Fix Windows support in coding-agent by hiding console windows and resolving venv Python paths

• Adds windowsHide: true to all spawn/spawnSync/execFile calls across the coding-agent and TUI packages so child processes no longer flash a console window on Windows.
• Introduces venvPythonPath() in bootstrap.ts to return the correct Python interpreter path per platform (Scripts/python.exe on Windows, bin/python on POSIX), replacing hardcoded bin/python paths used during venv bootstrapping and kernel readiness checks.
• Wraps directory fsync in a try/catch in command-recovery-journal.ts so journal writes succeed on filesystems that don't support fsync (e.g. Windows NTFS), while still completing via atomic rename.

^{Macroscope summarized 0df7848.}

[dwnmf]

Thanks

[hwei]

Real-user confirmation that this PR fixes all three Windows issues, tested on v0.7.1 (Windows 10 IoT Enterprise LTSC 2021):

1. Kernel bootstrap (bin/python vs Scripts/python.exe) — IPython kernel never started on Windows; each retry wiped and rebuilt the venv in an endless loop (issue Windows: kernel bootstrap uses venv bin/python, so the IPython kernel never starts and each retry wipes the venv #660). The venvPythonPath() change fixes it.
2. Directory fsync EPERM (CommandRecoveryJournal.compact()) — EPERM: operation not permitted, fsync on every ack_result; also tracked in Windows: fsync on a directory handle fails with EPERM #666 / fix(coding-agent): tolerate unsupported directory fsync #670.
3. Console window flicker — background child_process spawns from the console-less daemon/workers (git polling every ~15s, bash tool, IPython kernel python.exe, daemon catalog) flashed blank cmd windows at startup and on every tool call. The windowsHide sweep eliminates them.

I applied the equivalent changes to the installed v0.7.1 bundle and verified end-to-end on Windows: fresh daemon + real -p session runs clean (exit 0, zero EPERM, zero console windows).

The PR is currently mergeable but blocked on review (no conflicts, untouched since Aug 7). It covers the scope of #660, #666, and #670 in one change, so a review/merge here would unblock the most-reported Windows issues at once. Happy to help with rebasing or additional testing if anything is needed.

[sethkarten]

Thank you for the report and proposed work. This root cause is now covered by maintainer-owned stacked PR #1163, authored independently from upstream/main.

We did not inspect or reuse this PR's diff, branch, commits, implementation code, or tests; its public description/comments were used only as a bug report. To keep one review surface, this PR is superseded by #1163 and is being closed.

The complete review stack is #1158–#1165. It is being left unmerged for human review after CI and review-bot findings are cleared.