fix(api): evict API-side public-status cache on visibility change

[aprojic]

What

ProxyCacheInvalidationService.invalidatePublicCache evicted only the proxy-side public-status cache (proxy:sandbox-public:) on a visibility change. The API-side decision cache (preview:public:, short TTL) was left in place and re-populated the proxy cache on the next request, so a public→private change could take effect later than intended.

This evicts the API-side entry before the proxy-side entry. The proxy only re-queries the API on a cache miss, and such a miss can only happen after the proxy key is gone — so deleting the API key first means any re-query reads fresh state instead of the stale decision.

Test

Adds proxy-cache-invalidation.service.spec.ts:

• both keys are evicted on PUBLIC_STATUS_UPDATED
• the API-side key is evicted before the proxy-side key (the load-bearing ordering)
• eviction is best-effort — a Redis failure does not fail the visibility change

Verified the ordering test fails against a proxy-first implementation; nx run api:test for the suite passes, prettier + eslint clean.

---

Summary by cubic

Fixes stale public-status cache after sandbox visibility changes by evicting the API-side cache before the proxy cache. Prevents public→private changes from lagging and ensures requests read fresh state.

• Bug Fixes
  • Evict API decision cache first (preview:public:${sandboxId}), then proxy cache (proxy:sandbox-public:${sandboxId}) to avoid repopulating with stale data.
  • Added tests verifying both keys are evicted in that order and that eviction is best-effort (Redis failures don’t block visibility updates).

^{Written for commit 0a95dd8. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[itxaiohanglover]

Clean fix! Evicting both API-side and proxy-side caches ensures consistent public status. The test verifying both cache keys are deleted is thorough.