[Bug]: Skills marketplace returns empty against the current extensions manifest layout

[enyst]

Bug description

The skills marketplace loader checks for marketplaces/default.json and returns [] if it is absent before attempting manifest discovery (openhands-agent-server/openhands/agent_server/skills_service.py:706-738).

The current OpenHands/extensions repository uses .plugin/marketplace.json; its marketplaces/ directory contains large-codebase.json and openhands-extensions.json, not default.json. The plugin marketplace loader already handles this correctly by calling Marketplace.load(repo_path) first (plugins_service.py:331-357).

As a result, a cold /skills/marketplace load can be blank while /plugins/marketplace loads the same repository successfully. The skills path also caches empty failures for the full TTL, while the plugin path deliberately does not.

Expected behavior

Skills and plugins should derive their views from the same successfully fetched and parsed marketplace snapshot, using manifest discovery first and the explicit path only as fallback.

Suggested implementation

Add one small shared marketplace snapshot loader/cache backed by Marketplace.load. Fetch/parse once, cache only successful snapshots, and let skills/plugins derive their distinct response shapes while computing installation state fresh.

Acceptance criteria

• Skills load from the real .plugin/marketplace.json layout when marketplaces/default.json is absent.
• Custom explicit marketplace paths remain supported as fallback.
• Skills and plugins within the TTL use the same fetched/parsed snapshot.
• Transient fetch/parse failures do not cache an empty catalog.
• Existing plugin-over-skill name precedence, plugin filtering, installed-state freshness, and REST schemas remain unchanged.

Version

Current main at 6d3881035. Repository layout was independently verified through the GitHub API on 2026-08-27; existing issue search found no duplicate.

[github-actions]

⚠️ Not yet ready-for-dev

This issue does not yet meet the readiness criteria, so the
ready-for-dev label has not been applied (or has been removed).
The criteria are type-specific:

Bug reports (bug label, see .github/ISSUE_TEMPLATE/bug_template.yml):

• The ### Actual Behavior section must describe reproducible SDK steps
  and include a command such as python, pytest, uv, or pip.
• An ### Acceptance Criteria section with at least one checklist item (- [ ] …).

Enhancements (enhancement label, see .github/ISSUE_TEMPLATE/feature_request.yml):

• A ### Desired Behavior section.
• An ### Acceptance Criteria section with at least one checklist item.

What is missing:

• Fill in the ### Actual Behavior section with reproducible SDK steps and the observed result.

Edit the issue to address the gaps and the ready-for-dev label will be
applied automatically.

Note: Section headings require exact ### matches from the templates.
If a missing type label is reported, no action is needed from external
contributors — maintainers will add the label during triage.

This is an automated check — no AI was used to generate this comment.

[Epochex]

I have a tested draft patch in #4785. This issue is currently blocked by the repository''s ready-for-dev gate because the body predates the exact ### Actual Behavior heading requirement.

Could the author or a maintainer add this section to the issue body?

Actual Behavior

On current main, run uv run pytest tests/agent_server/test_marketplace_snapshot.py::test_manifest_discovery_precedes_explicit_path -q (test included in #4785) against a checkout with .plugin/marketplace.json but no marketplaces/default.json. The skills service returns an empty catalog before attempting manifest discovery, while the plugins path can load the same marketplace.

The existing Acceptance Criteria section already satisfies the other readiness requirement.