feat(realtime): Fase 2b.0 infra + first R-series tests green

Enable postgres_changes broadcasts on shopping_items / shopping_lists and prove
the path end-to-end with Vitest Realtime tests and a pgTAP configuration check.

Infra changes that were silently blocking events
- Migration 007: shopping_items + shopping_lists added to supabase_realtime
  publication with REPLICA IDENTITY FULL (UPDATE/DELETE payloads need the full
  row so list_id-based filters work and RLS can evaluate DELETE against OLD)
- Realtime service: DB_USER=supabase_admin (superuser; supabase_replication_admin
  lacks CREATE on the `realtime` schema that the service auto-creates per tenant)
- Realtime service: SELF_HOST_TENANT_NAME=realtime so the seed tenant name
  matches the default supabase-js resolves for localhost URLs (was realtime-dev
  → TenantNotFound)

Tests
- pgTAP 004_realtime_publication.sql — P-01..P-04: publication membership and
  REPLICA IDENTITY FULL for both shopping tables
- Vitest realtime-postgres-changes.test.ts — R-01 INSERT broadcast,
  R-02 UPDATE carries full row, R-03 list_id filter isolates events
- test-utils realtime-helpers.ts — subscribePostgresChanges() returns a
  waitFor(predicate, timeout) helper that captures the SUBSCRIBED handshake
  before returning so mutations issued right after are not lost
- createClientAs now calls realtime.setAuth(token) so the server evaluates
  RLS against the test user's JWT
- Justfile test-db now globs supabase/tests/*.sql so new pgTAP files are picked
  up automatically

Totals: 54→57 Vitest, 12→16 pgTAP, 15 Playwright = 88 tests green.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

supabase/migrations/007_realtime_publication.sql

@@ -0,0 +1,24 @@
+-- Migration 007: Realtime publication for shopping lists & items.
+--
+-- Supabase Realtime broadcasts Postgres changes through a logical-replication
+-- publication named `supabase_realtime`. Tables not in the publication emit
+-- no events, so nothing reaches subscribed clients.
+--
+-- REPLICA IDENTITY FULL makes UPDATE and DELETE events carry the entire row
+-- (not just the primary key). We need this for two reasons:
+--   1) Clients filter events by `list_id` on shopping_items — a PK-only payload
+--      on UPDATE/DELETE doesn't include list_id and the filter silently drops
+--      valid events.
+--   2) Supabase Realtime evaluates RLS against the row being broadcast; for
+--      DELETE events that means evaluating it against the OLD row, which is
+--      only available with REPLICA IDENTITY FULL.
+--
+-- Cost: logical-replication WAL entries grow by ~1 row width per mutation.
+-- For the shopping-lists workload (low write rate, small rows) the impact is
+-- negligible.
+
+ALTER PUBLICATION supabase_realtime ADD TABLE public.shopping_items;
+ALTER PUBLICATION supabase_realtime ADD TABLE public.shopping_lists;
+
+ALTER TABLE public.shopping_items REPLICA IDENTITY FULL;
+ALTER TABLE public.shopping_lists REPLICA IDENTITY FULL;