Split terra onto its own Supabase project - PLAN ONLY, no build, no migration until Elazar sees the plan

Elazar 2026-09-12 CLI, and he notes agents have talked him out of this before: 'i think i would just create a new supabase project called terra and have terra use its own project and leave enamel as a project for the future. the two things that should be working at their best are terra and movilba'. He is right and the evidence is from this week, not from principle. MEASURED: co-tenancy provides ZERO isolation today - relrowsecurity 0 of 77 relations, relforcerowsecurity 0 of 77, pg_policies in public 0, and BOTH apps' production pools authenticate as the project OWNER role (postgres.eprpywqwzsvrjeaforei), which owns all 77 public relations. Enamel's pool can DROP, TRUNCATE or re-ACL terra's tables right now; the only thing preventing it is that the code does not try. ENAMEL-28 states it in its own title. The shared surface is where the coordination cost lives: one vocabulary INSERT last night required an announce-before plus ACK-VERIFIED handshake between two db agents across two projects, and roughly 7 of enamel's 18 rows trace directly to two tenants in one database - ENAMEL-34 exists ONLY because documentoType was validated against the global catalog instead of the tenant scope. The cleartext credential exposure was ONE credential owning BOTH apps. THE ONE DECISION THE SPLIT FORCES, and it is a product call: EVO-83 is Elazar's own 2026-07-31 ruling, '2 yes central' - the client CR and questions system CENTRAL in enamel's DB, appKey-scoped, one portal UI. If terra moves, that system either STAYS in enamel and terra reaches it over HTTP instead of a DB call, or terra gets a copy and 'central' stops being true. pmmaster's read, for Elazar to accept or reject: new terra project, CR system stays central in enamel reached over HTTP. DELIVERABLE IS A PLAN, NOT A MIGRATION: inventory what moves, what stays, what duplicates; name every cross-tenant read in terra's src/ and enamel's; state the cutover sequence and the rollback; price it. Do NOT create a Supabase project, do not run a migration, do not change a DSN. Vocabulary tables duplicate cleanly - both tenants independently chose dni+pasaporte, so there is no divergence to reconcile. Class-A review by audit-terra-cc before any build GO.