bug(core): llm and setup subprocesses still open console windows on Windows

[Alan-TheGentleman]

📋 Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

📝 Bug Description

Follow-up to #599, which was fixed in #604 for the project-detection path only.

#604 introduced newProjectCommandContext in internal/project, a build-tagged helper that sets SysProcAttr{HideWindow: true} on Windows so git.exe subprocesses no longer allocate a visible console. It was wired into detectGitRootDir and detectFromGitRemote, the two call sites named in #599's evidence chain.

Two other subprocess call sites have the same problem and were deliberately left out of #604's scope:

• internal/llm/claude.go:140 — defaultRunCLI spawns the agent CLI (claude, opencode) via exec.CommandContext. On Windows this flashes a console window the same way, and it runs whenever an LLM-backed feature is invoked.
• internal/setup/setup.go:36 — runCommand uses exec.Command(...).CombinedOutput(). This one runs during interactive engram setup, where a console window is much less surprising, so it is lower priority.

🔄 Steps to Reproduce

On Windows, trigger any code path that reaches defaultRunCLI (an LLM-backed command) and observe the transient console window, same signature as #599: a conhost.exe / terminal window appearing and vanishing.

✅ Expected Behavior

Subprocesses spawned by Engram on Windows should not allocate a visible console.

❌ Actual Behavior

internal/llm and internal/setup subprocesses still allocate one.

📦 Affected Area

Core (internal/llm, internal/setup)

💡 Proposed Solution

Reuse the pattern from #604 rather than duplicating it. newProjectCommandContext currently lives in internal/project and is unexported, so lifting it into a small shared internal package (something like internal/proc) that project, llm, and setup can all import is probably cleaner than three build-tagged copies.

Note that internal/setup/setup.go wraps the call in a runCommand function variable for test injection, so the helper needs to fit that seam.

📎 Additional Context

Worth keeping the cross-compile check that #604's review established: GOOS=windows GOARCH=amd64 go build ./.... The Windows-only files never compile on macOS/Linux dev machines or in the default CI job, so they can break without anyone noticing until a Windows user reports it.

[Alan-TheGentleman]

@MarsSall this one is yours if you want it, as a direct continuation of #604.

You already built the piece it needs: newProjectCommandContext with the //go:build windows / !windows split and SysProcAttr{HideWindow: true}. What's left is applying the same treatment to the two subprocess call sites that were outside #599's reported path:

• internal/llm/claude.go:140 — defaultRunCLI, spawns the agent CLI. Same console flash, and it fires on any LLM-backed command.
• internal/setup/setup.go:36 — runCommand, during interactive engram setup. Lower priority since a console there is far less surprising.

The shape I'd suggest, and the reason I'm not just asking you to copy the helper: it currently lives unexported in internal/project, so a third build-tagged copy in each package would mean three places to keep in sync. Lifting it into a small shared internal package that project, llm and setup all import is cleaner. One gotcha — internal/setup/setup.go wraps the call in a runCommand function variable for test injection, so whatever you extract has to fit through that seam without breaking the existing tests.

Already labelled status:approved, so you're not blocked on process — open the PR whenever you're ready.

One more thing worth carrying over from #604: keep GOOS=windows GOARCH=amd64 go build ./... in your local loop. The Windows-only files never compile on macOS or Linux dev machines, nor in the default CI job, so a break there stays invisible until a Windows user reports it. Your #604 files were fine, but that was luck rather than process, and it's the main reason I checked it by hand during that review.

I couldn't assign this to you directly — GitHub only allows assignees with write access, and you're on read. So consider this the handoff. No pressure at all if you'd rather not pick it up; just say so and I'll leave it open for anyone.