kb-doctor: bootstrap flow — "finish my KB setup" installs the remaining plugins

[t-downing]

User-wide onboarding previously meant five copy-pasted lines (two marketplace adds, a per-plugin install loop, and the easy-to-forget ~/.claude/.kb-repos-dir line). This collapses it to two commands plus one sentence to Claude:

claude plugin marketplace add OCHA-DAP/ds-knowledge-base
claude plugin install kb-access@ds-team

then "finish my KB setup" in any session — the kb-doctor skill (which already audits plugin enablement) now also:

1. adds the hdx-ai-hub marketplace if missing,
2. offers and installs the missing sibling plugins (data-access, data-conventions, aa-methods, infra-ops, hdx@hdx-ai-hub) at user scope, one claude plugin install per plugin (the CLI takes no batch argument), confirming the list once since some users deliberately run a subset,
3. walks the user through choosing the KB location interactively (per kb-search — never silently defaulted), adopting any existing clone,
4. re-runs the doctor checks and shows the final table.

docs/USING.md quick start updated to match; the manual per-plugin path and the zero-command per-repo trust-prompt path are kept. No setup script introduced — the plugin remains the setup, with kb-doctor as the installer for the rest.

[zackarno]

Reviewed with independent verification — approving.

Verified:

• The referenced state surfaces are real and correctly named: ~/.claude/plugins/known_marketplaces.json holds marketplace keys, user-scope installs land in enabledPlugins in ~/.claude/settings.json. Checked on a live machine that happens to be exactly the bootstrap target state (only kb-access at user scope, no hdx-ai-hub marketplace) — the flow's preconditions are realistic, not hypothetical.
• CLI claims check out: claude plugin install --help confirms default --scope is user and a single <plugin> argument (no batch form) — the one-install-per-plugin loop is necessary, not a style choice.
• "run checks 1–6 above" matches the existing skill's numbering exactly.
• Description budget: 469 chars (per-skill cap 1024), aggregate ~2.9k of 6144 — and the eager-surface growth passes the D94 test: trigger phrases are how a skill fires (coordination, not shape), and the observed failure is named in the PR body (the easy-to-forget .kb-repos-dir line). CI green (lint-docs runs the assets gate + link check).
• No overlap with #505's USING.md section (different regions; PR is MERGEABLE, blocked only on this review).
• One-home-per-fact holds: step 3 defers to kb-search's location-choosing flow instead of duplicating it.

One non-blocking suggestion, fine as a follow-up: step 4 leaves the actual clone to the next session start, so a user who runs bootstrap and immediately asks a KB question still has nothing on disk, and the final table shows checks 1–2 failing with "wait for restart" as the remedy. kb-doctor could instead run kb_sync.sh straight from the plugin cache once .kb-repos-dir is written (check 3 already documents hand-running it) — then "finish my KB setup" actually finishes it, clone included, and the verify table ends green. Your call whether that's worth a line in this PR or a later tweak.