fix(skills): clear error message for stale skills.sh index entries

[Mibayy]

Closes #3259

Problem

The skills.sh index contains entries (vercel-react-best-practices, react-email, react-pdf, etc.) that appear in search results with high install counts but whose GitHub files no longer exist. When a user tries to install one, they get:

Error: Could not fetch 'skills-sh/vercel-labs/agent-skills/vercel-react-best-practices' from any source.

This looks like a user error (typo, wrong identifier) but is actually an index synchronisation issue on skills.sh's side — the skill was removed or renamed by its author.

Root cause

_resolve_source_meta_and_bundle() already distinguishes the two cases:

• meta != None, bundle == None → index hit, GitHub 404 (stale entry)
• meta == None, bundle == None → unknown identifier

But do_install used the same generic error message for both.

Changes

hermes_cli/skills_hub.py

do_install — split the error branch:

• Stale entry (meta found, no bundle): named error explaining the index entry is stale, that the skill may have been renamed or removed, and that this is not a user error.
• Unknown identifier (no meta, no bundle): original generic "Could not fetch" message preserved.

do_search — add a caveat footnote when results include skills.sh entries, explaining that the index may contain entries whose GitHub files no longer exist, and what to expect if install fails.

Before / After

Before:

Fetching: skills-sh/vercel-labs/agent-skills/vercel-react-best-practices
Error: Could not fetch 'skills-sh/vercel-labs/agent-skills/vercel-react-best-practices' from any source.

After:

Fetching: skills-sh/vercel-labs/agent-skills/vercel-react-best-practices
Error: 'skills-sh/vercel-labs/agent-skills/vercel-react-best-practices' appears in the skills-sh
index but the skill files no longer exist in the underlying repository (GitHub returned 404).
This is a stale index entry. The skill may have been renamed or removed by its author.

And in search results containing skills.sh entries:

Note: 3 result(s) come from the skills.sh index, which may contain entries whose GitHub files
have since been removed or renamed. If installation fails with a 'stale index entry' error,
the skill no longer exists at its listed path.

Tests

4 new unit tests:

• test_do_install_stale_index_shows_helpful_message — meta found, bundle None → stale message
• test_do_install_unknown_identifier_shows_generic_message — both None → generic message, no stale
• test_do_search_shows_skills_sh_caveat — results with skills-sh source → caveat shown
• test_do_search_no_caveat_for_official_only — official-only results → no caveat

[teknium1]

Thanks for improving the skills-hub failure message. The generic failure remains on current main at hermes_cli/skills_hub.py:545, so the underlying UX problem is still valid.

Problems

• The new meta is not None branch at hermes_cli/skills_hub.py:343 is not sufficient proof of a GitHub 404. On current main, HermesIndexSource.inspect() returns index metadata without fetching (tools/skills_hub.py:3886-3892), while GitHubSource.fetch() maps all download failures to None (tools/skills_hub.py:592-606). This can call a rate-limit or transport failure a stale entry.
• Current do_install() retains a rate-limit hint at hermes_cli/skills_hub.py:539-553 (added by 7e0e5ea03). The PR branch predates that path, so the stale branch needs to preserve it.

Suggested changes

• Carry a confirmed fetch status/reason through resolution, and reserve the stale-index message for a matching confirmed 404.
• Add 404, rate-limit, and generic-fetch-failure cases; the current fake source at tests/hermes_cli/test_skills_hub.py:258 returns bare None, so it cannot validate the proposed distinction.

Automated hermes-sweeper review.

[teknium1]

meta only proves that some source returned metadata. On current main the centralized index returns metadata without fetching, while GitHub fetch reduces 404s, rate limits, and other failures to None; please gate this message on a confirmed matching 404 and retain the existing rate-limit hint.

[teknium1]

Closing — superseded by #108906 (257a704d18d1 from @nikkoxgonzales' #106901 + 08bb58bd4a58). You were the earliest to propose naming the stale index entry; the landed version follows the same design and adds the guard the review asked for here (don't mislabel a rate-limited fetch as stale). Thanks; #3259 is closed.