fix(verify): tests check runs the target project's own interpreter

[kylewelsby]

Summary

• _run_impacted_pytest (the tests check inside roam verify) always shelled out with sys.executable. Under the documented uv tool install / pipx install path, that's roam's own isolated interpreter — it has neither pytest nor the target project's dependencies installed, so collection fails before any test runs, and the gate reports it as a hard-blocking failure: pytest exited 1 without a parsed passing result.
• This hits any project whose dependencies don't happen to already exist inside roam's own venv, which in practice is close to every real project using the recommended global install.
• The same bug class was already fixed in this release for the pre-push hook ("ran whatever python PATH resolved to, not the project's interpreter") — this closes the equivalent gap in verify's own tests check, which wasn't touched by that fix.

Fix

New _resolve_test_interpreter() walks up from the first impacted test file (not just root) looking for a .venv/venv, and falls back to sys.executable unchanged when none is found — so today's behaviour is preserved whenever roam is already running inside the project's own venv. Anchoring on the test file rather than root also resolves correctly for a monorepo subproject nested below the indexed root (e.g. a Python service in an otherwise non-Python repo), where the project-root directory itself has no venv at all.

Test plan

• 3 new regression tests in tests/test_verify_autofire_hardening.py: prefers the project's own root venv, prefers a venv nested under the target file over a root-level one, falls back to sys.executable when no project venv exists.
• uv run pytest tests/test_verify_autofire_hardening.py -v — 18/18 pass.
• uv run pytest tests/test_verify*.py -p no:randomly — 256/256 pass, run twice for determinism. (One flake surfaced under random ordering; reproduced identically on unpatched main, so it's pre-existing pytest-randomly + shared index-state flakiness, unrelated to this change.)
• uv run ruff check / uv run ruff format --diff on both changed files — clean.
• Manually reproduced the original bug end to end against a real target repo (Rails + a nested Python subproject with its own .venv) before writing the fix, and confirmed the patched build resolves and runs the correct interpreter there.

Searched issues, PRs and discussions on this repo first — found no prior report of this.

[Cranot]

Thanks for the careful write-up and the before/after checks. This addresses a real problem with isolated installs, and finding a nested project's environment is useful too.

I checked one extra case while reviewing this: two affected test files from sibling projects, each with its own environment. The current helper chooses whichever environment belongs to the first file, so reversing the file order changes the interpreter used for the whole batch. This was a focused check of the path-selection helper, not an end-to-end test run.

Before landing this, I'd like us to handle that mixed-project case explicitly—either run each group in its own environment or explain that the combined run cannot be completed. We should also keep environment discovery inside the intended project and report an unusable interpreter clearly. I'm keeping this contribution in view while finishing the current release checks; it hasn't been merged or released yet.