feat: detect down containers in preflight (+ pin release to 2.1.0)

[TerrorSquad]

Follow-up to the preflight work, answering the container-down and performance questions.

Container-down handling

A tool pinned to a ddev/docker backend previously passed preflight (container tools were assumed available) and then failed mid-run with a cryptic docker exec error if the container was down. Now preflight checks the container is running and fails fast:

run failed: cannot run hook, some tools are unavailable:
  - phpstan — container "my-app-web" is not running
install/start them, set SKIP_<TOOL>=1 to skip, or disable the tool in forge.toml

forge does not start the container — a commit hook must not spin up infrastructure. It tells you to ddev start and retry (or SKIP_/disable).

Performance (measured)

• Host preflight = exec.LookPath, ~20–28µs/tool — sub-millisecond for a whole hook, dwarfed by the tools themselves (10–1000ms each).
• Container check = docker inspect, memoized once per container per run (added in the previous PR), shared across preflight and execution.
• No meaningful slowdown; nothing worth caching across runs (would go stale when you install a tool).

Release

Includes Release-As: 2.1.0 to override the pending 3.0.0 release PR — per request, this ships as a minor. (The earlier feat! behavior change will still be noted in the changelog; say the word if you want that history reworded for a fully clean minor.)

Tests & verification

• New backend tests: container-down → error, host missing/present.
• Updated the missing-tool assertion to the new message.
• E2E verified: container-pinned tool with container down → clear preflight failure, exit 1.
• go build/vet/gofmt clean; full -race suite passes; site builds.

🤖 Generated with Claude Code

[TerrorSquad]

Self-review. Behavior verified end-to-end and the logic is sound. One test gap:

The DDEV preflight branch isn't directly covered. TestPreflightTool_DockerContainerDown exercises the shared isDockerContainerRunning path via DockerBackend, but the *DdevBackend case also does ddevContainerName (parses .ddev/config.yaml) and emits a distinct start it with ddev start message — none of which is tested. Adding a fixture test for it.

No correctness issues otherwise: auto-detect still falls back to host before reaching the ddev branch; memoization is shared with ResolveBackend; skip exemptions unchanged.