Run breeze from the locked dev/breeze environment

[potiuk]

Breeze was installed by resolving dev/breeze/pyproject.toml against the package index on every fresh environment — uvx --from ./dev/breeze in the shim, uv tool install --editable ./dev/breeze in CI. Neither reads dev/breeze/uv.lock, and neither applies the [tool.uv] exclude-newer buffer declared beside it, which governs project operations only. The committed lock recorded nothing, so an upstream release could change what breeze runs with no commit in this repository.

click 8.5.0 showed the cost (#72106): it added a help field to the argument info dict breeze hashes to detect command drift, so within the hour of its release every CI job resolved it, every command taking a positional argument hashed differently from its committed value, and static checks went red on every open PR regardless of what it touched. The lock said click 8.4.2 throughout, and the four-day exclude-newer buffer never applied.

The shim now runs uv run --project <worktree>/dev/breeze --locked breeze, and CI runs uv sync --project ./dev/breeze/ --locked instead of installing a global uv tool. Per-worktree isolation (ADR 0017) is unchanged; what changes is that dependencies come from the lock. ADR 0017 is amended in place.

The 38 command-output files move back to the hashes the locked click 8.4.2 produces — the exact content from before #72106, which is what a lock-honouring install regenerates. click 8.5.0 reaches breeze when the lock upgrade admits it (exclude-newer clears 2026-08-30), regenerating those files in the same PR as the bump.

Note for contributors: the shim body changed, so # breeze-shim-version moves to 2 — re-run ./scripts/tools/setup_breeze once after this merges.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines