[nicoloboschi]

Fixes #4466.

Root cause

The issue reports that _start_daemon_locked() bypasses _windows_gui_interpreter(). It doesn't — it reaches it through _find_api_command(), and the resolution works. The problem is what it resolves to.

A uv venv's Scripts\pythonw.exe is not an interpreter. It is a ~45KB trampoline that CreateProcess's the base interpreter recorded in pyvenv.cfg, and that relaunch lands on the CUI python.exe. Our DETACHED_PROCESS flags only ever applied to the trampoline, never to the process the trampoline went on to spawn — which is exactly the grandchild in the reported process tree:

venv\Scripts\pythonw.exe -m hindsight_api.main --daemon     # GUI trampoline, no window
  └─ .hermes-runtime\python\...\python.exe -m ... --daemon   # CUI, POPS WINDOW

So we correctly pick a GUI-subsystem launcher and it hands the work to a console one.

I also ruled out the other candidate: hindsight_api/daemon.py re-execs via sys.executable, which would be the CUI python.exe, but it returns early on win32 before the re-exec. Not involved.

Fix

Resolve the trampoline ourselves and launch the base pythonw.exe, with the venv's site-packages on PYTHONPATH so hindsight_api still imports from outside the venv.

Two guards keep it narrow:

• Only uv venvs. It fires only when pyvenv.cfg carries uv's own uv = marker. A stdlib venv's pythonw.exe is the GUI venvwlauncher, which already redirects to the base pythonw — bypassing that would drop the daemon out of its venv for no gain.
• Never break startup to avoid a flash. If the env isn't writable or site-packages is missing, the original stub is returned. A daemon that won't start is worse than a console window.

_windows_gui_interpreter keeps returning str | None; env is threaded in as an optional out-param, so no existing caller or test changed.

Relationship to #3103

PR #3103 was closed, not merged — contrary to the issue's note that it shipped in v0.10.0. Its code is not on main (_resolve_real_pythonw / _inject_venv_paths exist nowhere). The 0.10.0 changelog line "The embedded daemon no longer flashes console windows on Windows" refers to commit 3f14672ea, which only touched TypeScript (hindsight-all-npm, coding-agents/src/core/daemon.ts) and is filed under 0.9.2.

This PR differs from #3103 in two ways that matter:

• fix(embed): resolve uv venv stub pythonw to real GUI-subsystem interp… #3103 redirected every venv, including stdlib ones, which is an unjustified regression risk. This gates on the uv marker.
• fix(embed): resolve uv venv stub pythonw to real GUI-subsystem interp… #3103 returned a 2-tuple and changed _windows_gui_interpreter's return type, forcing every caller to unpack. The project bans multi-item tuple returns outright, "not even for internal/private functions". This uses a frozen UvTrampoline dataclass.

I also skipped #3103's .pth-file parsing: it existed to make pywintypes importable, and there is no pywin32 anywhere in this repo. Plain site-packages on PYTHONPATH is enough for our dependencies.

Testing

• Two regression tests: one for the uv trampoline case, one asserting stdlib venvs are left alone.
• 224 embed tests pass, lint.sh and ty clean.

Caveat worth a reviewer's attention: I could not verify this on Windows. The tests are fakes built from tmp_path, not real trampolines, and the evidence that uv's pythonw stub relaunches CUI python.exe is the process tree in the issue rather than something I reproduced. That assumption is what the whole fix rests on. Worth a manual windows-smoke.yml dispatch before merge; test-embed-windows will also run here.

Not fixed here

control_center/lifecycle.py:167 spawns with a bare sys.executable and never consults _windows_gui_interpreter, so the control center has its own console-flash path. Pre-existing and independent of this issue — happy to fold it in if you'd rather fix both at once.