build(make): prove setup worked instead of assuming pip's exit code (T-47)

pip install exits 0 whether the result is usable or not — that is the D-24
shape exactly, a step whose job is to not fail. On 2026-08-09 the venv here
existed and pip had already succeeded, but sqlalchemy was declared in
requirements.txt and not installed. That surfaced as 11 pytest collection
errors that read as broken imports rather than as an environment problem.

setup now ends with `pytest --collect-only tests/`, which exercises every
import the suite touches without running anything. pip check was considered
as a cheaper alternative and rejected: it only checks the installed set's
internal consistency against itself, so it would not have caught this case —
sqlalchemy was still present as another package's transitive dependency even
after being dropped from requirements.txt. collect-only checks declared vs.
actually usable directly, which is the axis that broke.

Verified: two clean runs (33.5s cold, 5.7s idempotent re-run, second changes
nothing). Reproduced the original failure by uninstalling sqlalchemy from an
otherwise-correct venv — collect-only alone then exits 2 with 11 collection
errors; make setup against that same state reinstalls it and exits 0 with
381/381 collected.

Co-Authored-By: Claude <noreply@anthropic.com>

Makefile

@@ -15,9 +15,23 @@ help: ## Show this help
 	  | awk 'BEGIN{FS=":.*?## "}{printf "  \033[36m%-14s\033[0m %s\n", $$1, $$2}'
 
 .PHONY: setup
-setup: ## Create the venv and install dependencies
+setup: ## Create the venv, install dependencies, and prove the result is usable
 	$(PYTHON) -m venv .venv
 	$(VENV)/bin/pip install -r requirements.txt -r dev-requirements.txt
+	# Exit 0 from pip install is not evidence (D-24) — it is the step's job not
+	# to fail, so a broken result and a working one look identical from here.
+	# On 2026-08-09 the venv existed and pip had exited 0, but sqlalchemy was
+	# declared in requirements.txt and not installed; that surfaced as 11
+	# pytest collection errors that read as broken imports, not as a setup
+	# problem. `--collect-only` exercises every import the suite touches
+	# without running a single test, so it catches exactly that class of
+	# drift and stays cheap. `pip check` was considered too, but it only
+	# verifies the *installed* set's internal consistency against itself —
+	# it would not have caught this case, because sqlalchemy was still
+	# present as another package's transitive dependency even when dropped
+	# from requirements.txt. collect-only checks declared-vs-actually-usable
+	# directly, which is the axis that broke.
+	$(VENV)/bin/python -m pytest --collect-only tests/
 
 .PHONY: test
 test: ## Run the test suite