Problem

The Playground remote service worker applies cacheFirstFetch() to same-origin WordPress REST requests. That cache uses ignoreSearch: true, so distinct dynamic requests such as /wp-json/example/v1/resource?ref=a and ?ref=b resolve to the first cached response.

This breaks hosts that self-host remote.html at the same origin as their application API. In WordPress Build, distinct project blueprint refs and server transients are correct, but switching projects hydrates the first project blueprint for every later ref.

Reproduction

1. Control a page with the Playground root service worker.
2. Request two same-origin REST URLs that differ only by query value.
3. Make the first response body identifiable as A and the second as B.
4. Observe that the service-worker-controlled browser receives A for both requests.
5. Fetch the same URLs outside the service worker and observe the correct A and B responses.

Root cause

packages/playground/remote/service-worker.ts sends all cacheable same-origin URLs except .php and scoped requests through cacheFirstFetch(). offline-mode-cache.ts calls Cache.match(request, { ignoreSearch: true }). /wp-json/ is dynamic but currently passes shouldCacheUrl().

Expected

Dynamic same-origin API routes such as /wp-json/ bypass the offline static-asset cache. Query-distinct responses must remain distinct.

Downstream evidence

Tracked by chubes4/wp-build#1274. A deterministic tiny -> large -> tiny project-switch replay produced distinct server artifacts and blueprint refs, while the browser hydrated the tiny nine-step blueprint for both refs. Direct HTTP hydration returned the correct distinct blueprints.