[Bug]: skills.sh listing URL fails when ClawHub has no federated copy #4167

Affected component

Skill source resolver / Toolbox → Skills.

Version and environment

WeKnora v0.8.2 Lite source build on macOS, with an isolated test-only SQLite database repaired using the already-merged upstream migration from #4060. The relevant parseSkillsShURL and fetchURL logic is also present on current main. This report is about source resolution, separate from the v0.8.2 SQLite migration issue #4058.

Steps to reproduce

1. Confirm the public skill is listed on skills.sh: acedatacloud/skills/suno-music. It has a visible install command, and searching Suno shows it in the directory.
2. In an authenticated WeKnora workspace, POST /api/v1/skills/catalog with {"source":"https://www.skills.sh/acedatacloud/skills/suno-music"}. The same behavior occurs from the Add Skill source field. Public registry/GitHub hosts were allowed through this local machine's synthetic DNS SSRF guard; the request reaches the remote install resolver.
3. Observe HTTP 400: skill source is invalid: download returned HTTP 404: Skill not found.
4. Use {"source":"https://github.com/AceDataCloud/Skills/tree/main/skills/suno-music"} in the same instance. It returns HTTP 201 with name suno-music and its current description.

Expected

A public skills.sh result with a GitHub install source should be importable from its listing URL, or WeKnora should clearly tell the user that this listing is not available through its current ClawHub federation and direct them to the GitHub source. The current documentation says skills.sh pages are supported, so a generic 404 is misleading.

Cause and scope

parseSkillsShURL maps every skills.sh/owner/repo/slug page to ClawHub's /api/v1/skills/{slug}/install?reference=skills-sh:owner/repo/slug. ClawHub returns 404 when a skills.sh entry has no federated ClawHub copy, even though skills.sh itself lists it. #2941 correctly added support for pages that are federated; this case is the remaining non-federated listing. I have not submitted a GitHub-path guessing fallback, because skill folders can be nested and the slug alone does not prove the archive subdirectory. A maintainer decision on an authoritative resolution path or an explicit unsupported-source message would avoid silently importing a different skill.

No credential or paid media call is needed to reproduce this import failure.