Improve CLI upgrade and feature discoverability for integrations

[PascalThuet]

Problem

I hit a confusing upgrade/discoverability issue while setting up a new Spec Kit project with Claude Code + Codex CLI.

The current GitHub code supports controlled multi-install integrations:

uvx --from git+https://github.com/github/spec-kit.git specify integration install codex --script sh
uvx --from git+https://github.com/github/spec-kit.git specify integration use claude

But my local CLI was older:

specify --version
# specify 0.8.2

So the local command still behaved like the old single-integration model:

Error: Integration 'claude' is already installed.
Run specify integration uninstall first, or use specify integration switch codex.

This made it look like multi-install was unsupported, even though it worked with the latest GitHub build.

Why this matters

uvx --from git+... runs a temporary latest build, but it does not update the local specify command.

That distinction is easy to miss, especially in agent-assisted workflows. The agent sees a real CLI error and may recommend uninstall/switch workarounds instead of detecting that the local CLI is simply too old.

Proposed improvements

I think this can be handled incrementally:

1. Add docs notes for features that require a minimum CLI version.
2. Clarify that uvx --from git+... does not update the local CLI.
3. Improve second-integration error messages so they distinguish:
   • replacing the current integration;
   • installing another integration alongside it;
   • upgrading the local CLI when the feature exists but the installed version is old.
4. Add specify version --features / --json so humans and agents can check local capability.
5. Optionally add specify check --latest and a future explicit self update / self upgrade.

Suggested first PR

Start with a docs-only PR:

• document the minimum version for controlled multi-install;
• explain temporary uvx runs vs local CLI updates;
• point users to specify self check or the explicit uv tool install ... --force command.

If that direction sounds good, I can split the rest into small follow-up PRs rather than one large change.