[Fix] Skills commands wait for remote catalog discovery

[roomote-roomote]

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Telegram.

What changed

• Return packaged, actor-authorized instance, and inline environment skill metadata immediately without waiting for marketplace or repository Git discovery.
• Mark the first snapshot as partial, refresh remote catalogs through a cache-owned background lifecycle with a 90-second deadline, two-refresh concurrency cap, retry delay, five-minute remote freshness, and 100-entry/15-minute retention bounds.
• Keep pagination pinned to one immutable visible snapshot; a completed refresh becomes the next snapshot and promotes only when the user starts again at page 1.
• Derive actor/revision-scoped cache keys from current local skill metadata, marketplace selections, and environment repository mappings, preserving authorization, precedence, and scoped duplicates.
• Record non-sensitive local/remote source timing and add focused coverage for cold response, refresh success/failure/retry, freshness, configuration revision, stable pagination, isolation, retention, and exact invocation loading.

Why this change was made

Production telemetry for the merged skills command showed a Telegram /skills 2 request spending 48.148 seconds in the webhook while its final Telegram send took only 839 ms. The command blocked its first response on remote Settings and repository discovery, then repeated that work for each page.

Impact

Cold commands now return a truthful local catalog with an explicit remote-discovery-pending notice; refreshed results cannot shift entries mid-pagination. A controlled cache-core measurement returned the partial snapshot in 0.265 ms while remote discovery remained unresolved, excluding local database/filesystem reads. Full skill instructions still resolve lazily through existing exact invocation paths. Production latency improvement remains unverified until this follow-up is reviewed and deployed.

[roomote-community]

1 issue outstanding. See task

• Timed-out remote catalog refreshes retain the active slot, preventing retries and eventually blocking all refreshes.

_{Reviewed 6ae48ba}

[roomote-community]

When the timeout wins this race, operation is still pending, so releaseOperation() has not run. The rejection path records failed, but leaves refreshOperationActive true and keeps the global activeRefreshes slot occupied; this entry consequently never passes the retry condition after retryAfter, and two hung discoveries prevent every other catalog from refreshing. Release the slot and clear the entry's active state on timeout (guarding the later completion), and cover a refresh that never settles.