fix(cli): launch subcommands with the active Python interpreter

[imMamdouhaboammar]

Problem

The ga console script can be installed and run from a virtual environment or another explicit Python interpreter, but every Python-based frontend command in ga_cli/cli.py starts with the literal executable name python.

That can resolve to a different interpreter than the one running ga, or fail entirely on systems where only python3 exists. It also conflicts with cmd_update(), which already uses sys.executable correctly.

Fix

Normalize only Python launcher commands inside launch_frontend(): when the command's first token is exactly python, replace it with sys.executable. Non-Python runtimes are left untouched.

This keeps the command registry readable and avoids editing each command definition separately.

Verification

TDD was performed on a separate validation branch:

1. Regression-only GitHub Actions run 31166383679 failed because launch_frontend() passed python instead of the active interpreter path; the non-Python launcher case already passed
2. The minimal dispatcher fix passed run 31166445434: compile, both regression tests, and git diff --check
3. This contribution branch is rebuilt directly from current main as one clean commit with no temporary CI files

Scope

• 1 CLI production file modified
• 1 focused regression-test file added
• 1 clean commit on top of current main
• no dependency or configuration changes

[cmygit]

Windows + uv reproduction & verification (real environment, not mocked)

I hit this exact bug on Windows 11 with uv run ga gui / ga tui2 / ga hub / ga cli: every frontend failed because the spawned python resolved to uv's managed interpreter (no venv site-packages, EXTERNALLY-MANAGED marker) — ModuleNotFoundError: requests, ModuleNotFoundError: PySide6, and tui2's pip auto-install rejected by PEP 668.

Root cause, confirmed by experiments (uv uv 0.12.1 (329541a50 2026-07-31 x86_64-pc-windows-msvc), Python 3.12):

1. PATH ordering cannot help. Windows CreateProcess search order is: parent exe dir → cwd → System32 → Windows → PATH last. Removing the managed-python dir from PATH changed nothing — Popen(["python"]) still resolved via the parent's executable directory.
2. uv's venv python.exe is a launcher stub. The child process actually runs the managed interpreter: inside uv run python, sys._base_executable points to ~/.local/share/uv/python/.../python.exe. The child env even has correct VIRTUAL_ENV and PATH[0]=<venv>/Scripts, but the bare managed interpreter has no venv context.
3. Explicitly invoking <venv>/Scripts/python.exe by full path works fine — confirming the fix direction.

After applying this PR's one-line change (full_cmd[0] = sys.executable), all four frontends (cli, tui2, gui, hub) start successfully from uv run ga ... on this machine.

Thanks for the focused regression tests — they cover exactly the dispatch boundary. This also explains the closed PRs #551/#502: the bug only surfaces when ga itself runs inside an uv-created venv (launcher stub + parent-exe-dir lookup), which is why it survived so many versions.