Harden user-facing command installation and readiness checks

[daniel-kindl]

Problem

A repo-wide review found a class of component bugs where a command exists in bin/, but the component model and verification do not prove that the command is actually installed and usable from the intended environment.

The original symptom was:

$ repo-labels check
bash: repo-labels: command not found

This is not isolated.

Confirmed affected components

repo-labels

• kind: tool
• documented as a normal user-facing command
• install: null
• doctor executes the repo-local bin/repo-labels
• verification proves the repo-local file exists/compiles/tests, but does not prove repo-labels resolves on PATH

repo-meta

Same structural bug as repo-labels:

• kind: tool
• documented as a normal user-facing command
• install: null
• doctor executes the repo-local bin/repo-meta
• verification does not prove the public command is installed

agentbox

agentbox does have an installer, but its component doctor runs bin/agentbox doctor directly. If ~/.local/bin/agentbox is deleted while the underlying runtime remains healthy, the doctor can still report the component ready and the installer can skip restoring the public command.

devbox and agentq already model this correctly: their doctors first prove the installed entry point exists.

Capability drift

The same review found capability declarations that do not match runtime requirements:

• repo-labels requires gh but declares only python3.
• repo-meta requires gh but declares only python3.
• agentbox doctor/runtime also require tools such as git and python3, but its component contract currently understates those requirements.

The capability layer already defines gh, git, python3, etc.; the affected components should use it instead of failing late.

Goal

Make the component contract guarantee that every supported user-facing command is actually exposed where users are told to invoke it, and make readiness/verification test the installed interface rather than only the implementation file in the checkout.

Proposed direction

• Add idempotent installers for repo-labels and repo-meta, wiring their commands into ~/.local/bin on the host.
• Change their doctors to validate the installed command, not only bin/... in the checkout.
• Add a component-level doctor wrapper for agentbox that first proves ~/.local/bin/agentbox exists, then delegates to its runtime doctor.
• Correct capability declarations for the affected tools.
• Add generic component/verification coverage so a future kind: tool command cannot pass merely because its source executable exists.

Do not hard-code only these three names if the invariant can be expressed generically.

Acceptance criteria

• A fresh ./install.sh --components repo-labels makes repo-labels callable from a normal host shell.
• A fresh ./install.sh --components repo-meta makes repo-meta callable from a normal host shell.
• Deleting an installed command and rerunning its component installation restores it instead of reporting ALREADY READY.
• agentbox no longer reports ready when its host entry point is absent.
• repo-labels and repo-meta declare gh as a required capability.
• agentbox declares the capabilities its component actually depends on, or the code documents why a requirement is intentionally checked at runtime instead.
• Focused verification proves the public commands are installed/resolvable from their intended execution environment.
• Add a regression test for the original repo-labels: command not found class of failure.
• ./verify.sh remains green.