PostgREST URL-keyed cache returns deleted rows; survives DELETE, `NOTIFY pgrst, 'reload schema'`, and project restart

# Bug report - [x] I confirm this is a bug with Supabase, not with my own application. - [x] I confirm I have searched the Docs, GitHub Discussions, and Discord. ## Bug description A REST API response cache somewhere between the client and PostgREST is serving rows that no longer exist in the database. The cache is keyed on the **exact** URL string — the same query with reordered params returns the correct (empty) result. Cache invalidation does not occur on table DELETE, on `NOTIFY pgrst, 'reload schema'`, or on a project restart from the Supabase dashboard. This is a security-relevant bug because RLS is correctly enforced at the Postgres level but the cached responses bypass it. ## Project ref `zyaisvsyeyyiuathvjsv` (region: eu-west-3) ## Reproduction The `profiles` table had 10 seed accounts with `email LIKE '%@venturedeal.mock'`. RLS is enabled with `relrowsecurity=true, relforcerowsecurity=true` and policies that restrict SELECT to own-row + admin (admin checked via inline `EXISTS` against `user_roles`). ### Step 1 — confirm Postgres correctly applies RLS ```sql SET ROLE authenticated; SET request.jwt.claim.sub TO '<any-authenticated-user-uuid>'; SET request.jwt.claim.role TO 'authenticated'; SELECT count(*) FROM profiles WHERE id != '<the-same-uuid>' LIMIT 5; -- Returns: 0 ✅ (RLS correctly blocks cross-user reads) RESET ROLE; ``` ### Step 2 — same query via PostgREST returns 5 deleted rows ```bash curl -H "apikey: <anon>" -H "Authorization: Bearer <user JWT, role=authenticated>" \ "https://zyaisvsyeyyiuathvjsv.supabase.co/rest/v1/profiles?select=*&id=neq.<uuid>&limit=5" # Returns: 5 rows, including saasanalyticsplatform@venturedeal.mock # ❌ All 5 rows have been deleted from the table: # DELETE FROM public.profiles WHERE email LIKE '%@venturedeal.mock'; # Confirmed gone via SELECT * FROM profiles WHERE email LIKE '%@venturedeal.mock' # → 0 rows ``` ### Step 3 — cache key is the exact URL string Same query, different param order → fresh result: ``` ?…