feat(runtime): suggest cached extra registry skills

[Audacity88]

Summary

• Base branch: master (all contributions)
• What changed and why:
  • Missing-skill install suggestions now read enabled cached extra skill registries as well as the default cached skills-registry.
  • Extra-registry suggestions render install commands as zeroclaw skills install registry:<name>/<skill>, matching the install source added by feat(skills): user-configured extra skill registries via registry:<name>/<skill> #7827.
  • The catalog skips disabled extra registries, non-git registry kinds, invalid extra-registry names, and cached skill directories that do not match the installer source grammar.
  • Markdown skill metadata without a frontmatter name still displays the bare skill directory name instead of the full registry:<name>/<skill> source, keeping suggestion names concise while the install command includes the registry prefix.
• Scope boundary: This does not add live registry fetch/clone behavior, auto-install, plugin install suggestions, composer-time suggestions, skill-body matching, memory writes, or prompt mutation. The remaining plugin half of [Feature]: Prompt-triggered install suggestions for missing skills and plugins #6289 still needs plugin registry search/install-by-name before suggestion wiring can close it.
• Blast radius: Runtime missing-skill suggestion rendering for CLI one-shot, interactive CLI, and channel process_message paths. Agent-loop call sites now forward configured extra registries into the existing suggestion renderer, but this does not change agent orchestration, persona, tool execution, the install path, or the registry sync path.
• Linked issue(s): Related [Feature]: Prompt-triggered install suggestions for missing skills and plugins #6289, feat(skills): user-configured extra skill registries via registry:<name>/<skill> #7827
• Labels: enhancement, risk: high, size: S, agent, runtime, skills, priority:p2

Validation Evidence (required)

• Commands run and tail output:

cargo fmt -- --check
PASS

cargo test -p zeroclaw-runtime cached_registry_catalog --lib
PASS: 5 passed; 0 failed; 0 ignored; 2344 filtered out

cargo test -p zeroclaw-runtime skills::suggestions::tests --lib
PASS: 16 passed; 0 failed; 0 ignored; 2335 filtered out

git diff --check
PASS

• Beyond CI — what did you manually verify? Manual source review confirmed all three runtime suggestion call sites pass config.skills.extra_registries, and the extra-registry source text now reuses the installer grammar guard before rendering registry:<name>/<skill>.
• If any command was intentionally skipped, why: Workspace clippy and full-workspace readiness validation were not run for this focused packet. Because this is risk: high runtime code, run broad readiness validation before maintainer sign-off.

Security & Privacy Impact (required)

• New permissions, capabilities, or file system access scope? Yes
• New external network calls? No
• Secrets / tokens / credentials handling changed? No
• PII, real identities, or personal data in diff, tests, fixtures, or docs? No
• If any Yes, describe the risk and mitigation: Suggestions now read metadata from already-cached extra-registry skill directories under the existing ZeroClaw data directory. The path is limited to enabled git extra registries, validates registry and skill source names, reads metadata manifests/frontmatter only, and does not fetch, install, execute scripts, or read skill bodies. The runtime kind == "git" filter is defensive; current config validation already rejects other extra-registry kinds.

Compatibility (required)

• Backward compatible? Yes
• Config / env / CLI surface changed? No
• If No or Yes to either: exact upgrade steps for existing users: No upgrade required. Users only see extra-registry suggestions when they already have install suggestions enabled and an enabled git extra registry cached locally.

Rollback (required for risk: medium and risk: high)

• Fast rollback command/path: Revert this PR. Operators can also disable the suggestion path with skills.install_suggestions.enabled = false.
• Feature flags or config toggles: skills.install_suggestions.enabled = false; disabling or removing an extra registry also prevents that registry from contributing suggestions.
• Observable failure symptoms: Unexpected "missing skill" suggestion text, a zeroclaw skills install registry:<name>/<skill> command for a skill the operator did not expect, or warning logs for malformed cached registry metadata.

Supersede Attribution (required only when Supersedes # is used)

• Superseded PRs + authors (#<pr> by @<author>, one per line): Not applicable.
• Scope materially carried forward: Not applicable.
• Co-authored-by trailers added in commit messages for incorporated contributors? No
• If No, why (inspiration-only, no direct code/design carry-over): This is a fresh narrow follow-up to [Feature]: Prompt-triggered install suggestions for missing skills and plugins #6289/feat(skills): user-configured extra skill registries via registry:<name>/<skill> #7827, with no superseded PR code carried forward.

[singlerider]

Direction (draft, no verdict): registry.kind == "git" is a string compare against the schema's own default_extra_registry_kind() -> "git". The schema field ExternalRegistry.kind is a String today, so this is the canonical comparison given the current shape, but this is the first runtime branch on kind. Since the schema comment already says only git is supported and other protocols are reserved, this is the cheapest moment to promote kind to a real enum in zeroclaw-config so the filter reads registry.kind == RegistryKind::Git and every future consumer branches on the typed variant instead of a literal. Not blocking the draft, but worth doing here rather than after more call sites accrete.

[singlerider]

Draft, direction only, no verdict. I read both files and the new test block.

Direction notes:

1. The constant cleanup is the right move. Pulling SKILLS_REGISTRY_DIR_NAME and EXTRA_REGISTRY_DIR_PREFIX from the parent module and dropping the inline "skills-registry" literal means the cache path now reads from one canonical source. Keep going in that direction.

2. Left an inline note on registry.kind == "git". The schema field is a String today so the compare is canonical for now, but this is the first runtime consumer that branches on kind, and the schema doc already reserves other protocols. Promoting kind to an enum in zeroclaw-config now is cheaper than after more call sites land.

3. The is_valid_name guard plus the is_registry_source check inside load_cached_registry_skill_capabilities is good defense: an invalid alias or a non-registry source name is skipped rather than producing a bogus registry:<name>/<skill> install spec. The skips_invalid_extra_registry_skill_sources test pins exactly that.

4. The fallback_name threading through load_skill_package_metadata and load_markdown_skill_package_metadata is correct. For extra registries the source becomes registry:<name>/<skill> while the displayed name falls back to the bare skill dir name rather than the qualified source. That is the behavior you want in the suggestion text.

5. Test coverage is solid for a draft: enabled-included, disabled-skipped, non-git-skipped, invalid-source-skipped, plus the existing default-registry cases still pass with the new &[] argument. The disabled and non-git tests assert an empty catalog, which is the meaningful negative.

One thing to confirm before you flip it out of draft: the sort now runs once in load_cached_installable_skill_capabilities after both the default and extra registries are merged, rather than per-registry. That is correct for a stable global order, just make sure the suggestion-selection logic does not assume the default registry sorts first.

Flag me when it is ready for a verdict.