add-clilisted

# /add-cli Wire a CLI into the toolbox image. The work is mechanical but spread across **four files** (five when the tool persists state), and a gap in any one silently regresses something — Renovate stops bumping the version, a catalog bijection test fails the build, smoke-test blesses a broken binary, or `<tool> auth login` writes to a tmpfs that vanishes on `toolbox stop`. Apply every edit yourself and finish on the gate; a checklist handed back to the user is not the deliverable. Two facts shape every edit here: - **Every CLI installs unconditionally.** No `INSTALL_<TOOL>` ARG, no `tools.<key>: false`, no skip-guard in the layer — the legacy `tools:` config block is gone. Leave opt-out plumbing out. - **`internal/catalog/catalog.go` declares what tools exist.** The Dockerfile installs; the catalog *declares*, and that declaration drives `inherit_host_auth` eligibility, the init.d bijection and "what's actually in this image". The image is always the canonical `:latest` from GHCR (no per-build hash), so nothing you add has to preserve hash stability — but two Go tests fail the build when the catalog and the image/init.d drift apart (step 3). ## When to branch Classify the CLI first. Grep, don't guess: ```bash grep -n "<TOOL>_VERSION" internal/build/assets/Dockerfile grep -n "\"<tool>\"" internal/catalog/catalog.go grep -n "<tool>" internal/build/assets/smoke-test.sh grep -n "\"~/.toolbox/<tool>\"" internal/mountplan/defaults.go grep -n "<TOOL>_VERSION" renovate.json