perf(registry): cache discovery index responses

[ricardo-devis-agullo]

Problem: GET / (packages/oc/src/registry/routes/index.ts) called repository.getComponent() for EVERY component on EVERY request, then re-rendered the whole index view (incl. 1300-line CSS) per HTML hit.

Fix:

• Per-registry-instance response cache (new helper packages/oc/src/registry/routes/discovery-cache.ts) keyed by componentsList.lastEdit (read via getComponentsDetails, advances on publish/poll) + query variant (state/meta/theme/baseUrl/discovery flags, HTML vs JSON).
• Repeat hit costs one cheap lastEdit read; all getComponent calls and the view re-render are skipped. HTML-with-query bypasses the cache (unbounded cardinality).
• JSON discovery responses now send Cache-Control: public, max-age=.
• Local/dev registries (getComponentsDetails -> null) and old mocks keep exact prior behaviour.

Invalidation: lastEdit generation change drops the previous generation (also the memory bound); plus a 50-variant cap per generation.

Verify:

• New test/unit/registry-routes-index-cache.js (11 specs): hit skips component fetches, lastEdit change refetches, variants don't collide, Cache-Control present on JSON (miss+hit) and absent on HTML, dev fallback uncached-but-correct.
• Full packages/oc suite (npm run test-silent): 1108 passing, 0 failing, twice.
• Note: one earlier full run showed 10 failures in registry-with-fallback acceptance (wrong-server symptoms on shared fixed ports 3030/3031); fallback spec passes 8/8 in isolation and both subsequent full runs are green, so this is a pre-existing port-reuse flake unrelated to this diff (per-instance cache, no shared state, no lifecycle changes).