fix(windows): Store python3 shim aborts install.sh and silently disables observe.sh

[juanparisma]

Problem

On Windows, python3 resolves to the Microsoft Store alias shim. It answers command -v python3 (so detection thinks Python exists) but it does not execute — it prints a "Python was not found; install from the Store…" notice to stderr and exits non-zero.

Two concrete failures on a real Windows install (Git-Bash, Python 3.12 via py):

1. install.sh aborts the entire install. Step 1 runs PYTHON_VER=$($PYTHON_CMD --version) with PYTHON_CMD=python3. The shim exits non-zero, and under set -e the whole installer dies at the prerequisites step — before copying a single file. The user sees a half-printed prereq check and nothing installed.
2. observe.sh silently no-ops. It picks python3 (the shim) without validating it, so every PreToolUse/PostToolUse hook runs the shim, which writes no observation. The learning system looks installed but never records anything.

Fix

Both files now iterate candidates — py -3 first (the real Windows launcher), then python3, python, python3.12/.11/.10 — and only accept a command whose --version actually reports Python 3.x. The version echo in install.sh is guarded with || true so a stray shim can't abort under set -e.

No behaviour change on macOS/Linux, where python3 is the real interpreter and is selected on the second iteration (the py -3 launcher doesn't exist there, so command -v py simply fails and the loop moves on).

Verified

Ran the patched install.sh on Windows with the Store shim on PATH: detects Python 3.12.10 and completes all 8 steps cleanly (previously aborted at step 1). observe.sh now writes observations. bash -n passes on both.

[Luispitik]

Thanks @juanparisma — excellent diagnosis, and verified end to end: install.sh runs under set -e and PYTHON_VER=$(python3 --version) had no guard, so the Store shim aborts the whole install at step 1; and observe.sh accepted python3 unvalidated and silently no-oped. The candidate loop with py -3 first is the right approach, and the PR applies clean on v4.6.1.

One blocking issue (verified empirically): the pinned regex Python 3\.(9|10|11|12|13) rejects Python 3.14.2 — and 3.14 is the current stable. On a Linux/macOS machine with only 3.14, today's main works (it accepts python3 unvalidated), and this PR would disable observe.sh silently there — the same failure class the PR is fixing. One-line fix in both files:

grep -qE "^Python 3\.(9|[1-9][0-9])\."   # 3.9+ with no upper pin; still rejects 2.x and 3.0-3.8

(or simply "Python 3\." if you don't want to drop 3.8 — the shim never prints that string.)

Non-blocking suggestions:

• cmd=$(echo "$candidate" | awk '{print $1}') forks twice per candidate inside observe.sh, which runs on every PreToolUse/PostToolUse — native cmd=${candidate%% *} is fork-free.
• A regression test would lock this in: a fake python3 on PATH that answers command -v but exits non-zero on --version, asserting the loop skips it, plus a case asserting Python 3.14.0 passes the check.
• install.bat has the same shim misdetection (where python3, lines 53-63) — fine as a separate follow-up.

Transparency note: #25 (just opened) bundles this same candidate-loop detection — credited to you in the commit and the CHANGELOG entry — together with two unrelated fixes, using the open-ended version check. Whichever lands first, the diagnosis here is yours; if #25 merges first I'll close this one with credit rather than ask you to rebase a superseded diff. Thanks again for the report quality.