[follow-up] Catalog popularity cache and regression test gaps

[Dumbris]

Remaining low-priority catalog popularity follow-ups from PR #1408:

• Avoid holding the provider mutex during the bbolt deletion transaction on cache-cap eviction; add a concurrent lookup/eviction regression test.
• Add provider-level request-count coverage proving the rolling GitHub budget gate is enforced, not only that the budget helper works.
• Assert fresh positive and negative cache entries do not enqueue another request before their TTL expires.
• Add an environment regression case where only generic GITHUB_TOKEN is set; it must not be sent as Authorization or select the authenticated budget.
• Compare the popularity request User-Agent against the exact versioned registryUserAgent() value; Go's default User-Agent currently makes a non-empty assertion pass without the required header.
• Cover breaker recovery after the injected clock passes reset, plus 429/Retry-After and low-remaining response paths.
• Reconcile the lazy-load wording/test with the provider's eager preload behavior so the test exercises the intended contract or is renamed to match it.

These are narrow performance and regression-test gaps. The main behavior and all current CI checks passed; live REST, CLI, MCP, and Web smoke verification passed on merged main.