detect blesses broken/planted tools (0-byte binaries, planted go.exe)

[ryanjmichie-git]

Found by the v1.1.0 adversarial stress sweep (refuter-confirmed). Defensive/robustness, not a provenance falsehood — deferred from v1.1.0.

• A 0-byte or non-executable node_modules/.bin/eslint (extensionless or .cmd) is reported as an available linter, because find_js_tool checks only candidate.exists() (forgeproof.py ~361). Running it later just fails the lint; no false attestation.
• .venv/Scripts/python.exe that is 0-byte/broken makes detect raise an unhandled OSError and emit NO JSON (violates 'detect always emits valid JSON'). Should fall back and report runtime_available: false.
• go.mod plus a planted go executable in the project root makes detect report runtime_available: true for Go with no real toolchain (PATH/cwd confusion).

Fix direction: treat 0-byte/non-executable tool files as unavailable; wrap the venv interpreter probe so a broken exe degrades to unavailable rather than crashing; resolve tool executables via PATH only (not cwd) for Go.

Impact: a broken tool yields a failed/absent lint, never a false 'verified'. Low severity.

[ryanjmichie-git]

Partially fixed in v1.2.0 (PR #11): the broken/0-byte venv interpreter no longer crashes detect — it degrades to runtime_available: false with valid JSON (the invariant violation). Covered by TestDetectBrokenVenv.

Remaining scope (deferred, detection-quality): 0-byte/non-executable node_modules/.bin tools still reported as available; planted go executable in the project root still blesses the Go toolchain (resolve via PATH only). Impact unchanged: a broken tool yields a failed/absent lint, never a false 'verified'.