Task: Implement Hotfix: resolve the venv interpreter by probe in compass.sh

The Continuous Windows job stops in its Setup Database step with exit

1. The step runs compass.sh db recreate, and the wrapper reaches its

requirements branch, which runs $VENV_BIN/python3. On Windows that path does not exist. The venv module writes python.exe on Windows whatever interpreter name creates the environment, so the hard-coded python3 name is wrong there.

The wrapper now resolves the interpreter once, by probe, and drives both pip install lines and the compass CLI call through the resolved path. On Linux and macOS the probe selects python3 as before, so nothing changes for those platforms.

• compass.sh names no venv interpreter directly. It probes a candidate list and uses the first candidate that exists.
• Both pip install lines and the CLI call run through the resolved path.
• bash -n is clean, and the probe picks python3 for a POSIX venv and python.exe for a Windows venv that holds only that name.
• The probe carries a test. test_venv_python_probe.py runs the probe function taken from the wrapper against four venv layouts and against a directory that holds no interpreter at all.
• compass runs unchanged on Linux: same output, no pip install, no change to the requirements stamp.
• The python-tooling class checks pass: the compass test suite and the drift checks.

1. Root-cause the failure from the CI logs and the CPython venv source. The failing line and the missing path are in the job log; the naming rule is in Lib/venv/__init__.py, which writes python.exe on win32. The previous fix in sprint 24 drove pip through the interpreter module to dodge the pip self-lock, but it kept the python3 name, which is the part that Windows does not have.
2. Add the probe after the venv bootstrap block, before the requirements branch. Prefer python3, then python3.exe, then python, then python.exe.
3. Route the pip upgrade, the requirements install and the CLI call through the resolved path.
4. Verify with bash -n, with four simulated venv layouts, and with a real compass run on Linux. Keep the layout cases as a test, so that the probe cannot regress without a red suite.
5. Run the python-tooling class checks.
6. Close the task and story bookkeeping, then raise one PR that carries this fix together with the Linux gcc fix.

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Local review of the diff, per the code-review-pr pass.

compass.sh no longer assumes that a virtual environment holds python3. The wrapper resolves the interpreter once, at resolve_venv_python(), and uses the first of python3, python3.exe, python and python.exe that exists. Both pip install lines and the compass CLI call run through the resolved path. On Linux and macOS the probe selects python3, so nothing changes there.

projects/ores.compass/tests/test_venv_python_probe.py covers the probe. Each case lifts the function out of the wrapper and runs it against a fake venv, so the candidate list under test is the list that ships. Four layouts pass, plus a venv directory that holds no interpreter, which falls back to the POSIX name.

Local verification: bash -n is clean, the simulated layouts resolve as the table above records, and compass fleet on Linux prints the same table as before the change.

The python-tooling class checks passed: the compass suite is green, 164 passed and 1 skipped, and the drift checks report no drift once the tree is committed.

The Windows job itself is untested here, because this host has no Windows toolchain. The next Continuous Windows run is the proof.