install --source: honour the source KB's own registry declaration (skills prefix)

[rucka]

Problem

An external KB declares its own registries in its pair.config.json (e.g. skills.prefix: "acme-kb"), but pair install --source <kb> resolves the consuming project's config (loadConfigWithOverrides), never the source KB's. With a default consuming project the KB's skills therefore install as pair-example-skill instead of acme-kb-example-skill, and the maintainer's declared namespacing silently does not apply.

Today the only workaround is manual: copy the KB's pair.config.json into the consuming project. #391 documents that caveat in external-kb.mdx, the scaffolded README and the seed skill.

Expected

install --source can honour the source KB's own registry declaration (at minimum the skills prefix), so a KB's namespacing survives installation without the consumer hand-copying config.

Acceptance Criteria

• AC1 — Given an external KB declaring skills.prefix: "acme-kb", when a default-configured project runs install --source <kb>, then its skills install as acme-kb-<skill>.
• AC2 — Given a consuming project that has deliberately overridden the registry, when install runs, then the project's own configuration still wins (documented precedence, no silent surprise).
• AC3 — e2e/round-trip coverage proving the prefix survives without copying the KB's config, and the caveats removed from external-kb.mdx, the scaffolded README template and the seed skill template.

Notes

• Flagged in [US-279] feat: pair-cli scaffold-kb — external KB repo + release script (reuses pair package) #391 (story External KB scaffold via pair-cli — pure KB repo + release script (reuses pair package) #279) and confirmed in review; install-side change for all sources, out of External KB scaffold via pair-cli — pure KB repo + release script (reuses pair package) #279's scope.