Fix ctl Python wrapper ownership

[franksong2702]

Thinking Path

PR #2171 exposed a Python 3.13 failure in tests/test_ctl_script.py. The failure is outside the session-response performance diff: ctl.sh start can launch a daemon through a custom HERMES_WEBUI_PYTHON wrapper, but status / stop only recognize process args containing bootstrap.py, server.py, or start.sh.

What Changed

• Persist the resolved Python executable in webui.ctl.env as PYTHON_EXE.
• Let _is_owned_webui_pid() recognize the recorded Python wrapper path while preserving the existing repo-root state guard.
• Stabilize the ctl tests by waiting for the fake wrapper log before reading it.
• Add an Unreleased changelog entry.

Why It Matters

A daemon started through an explicit Python wrapper should still be treated as the ctl-owned WebUI process. Without this, status can report stopped and stop can leave the wrapper process running, which is what caused the Python 3.13 CI failure observed from #2171.

Verification

• uv run --python 3.13 --with pytest --with pytest-timeout pytest -q tests/test_ctl_script.py -vv (4 passed)
• /Users/xuefusong/hermes-webui/.venv/bin/python -m pytest -q tests/test_ctl_script.py tests/test_ctl_bash32_compat.py (9 passed)
• bash -n ctl.sh
• git diff --check

Risks

Low. Ownership still requires the ctl state file and matching repo root before considering either known WebUI entrypoints or the recorded Python executable path.

Related

Closes #2172.
Follow-up from #2171 CI investigation.

Model Used

GPT-5.4 via Codex CLI.