DR-032 — Every api-surface change ships its companion exposure migration in the SAME batch

Extends DR-030 from renames to the full api-surface class, enforced three times in the S445 GO#2 apply: (1) a base-table ADD COLUMN leaves the api.* view’s fixed SELECT list silently missing the new columns (the view “works” while omitting data — worse than an error); (2) a new public.* RPC is unreachable via supabase-js (PGRST202) until an api.<fn> wrapper exists (convention: LANGUAGE sql SECURITY INVOKER passthrough per scripts/generate-api-views.ts emitFunction(); precedent 20260703210000_id138_api_rpc_wrappers.sql). Any migration that adds columns to a SURFACE_TABLES entry or creates a client-called RPC MUST ship the companion view-regen / wrapper migration in the same push batch, sorted after it. Enforcement reality (corrected S499): check-api-view-coverage.ts INV-4 catches missing view columns after the fact; generate-api-views.ts --check exists but is wired into no workflow — the same-batch rule itself is authoring discipline, not a gate.