Database slice: node-pg-migrate replaces monolithic schema, RLS and lifecycle work added

@hoogvliets carved the data layer out of a larger disclosure into a standalone PR. The main move is a shift from a one-shot schema apply to a managed `node-pg-migrate` system - worth evaluating if you've been wrestling with how to evolve the upstream schema over time.

multi-tenantinfrastructure

The migration tooling lands forward migration, single-step rollback, and new-migration-creation scripts. A one-shot baseline file handles fresh Supabase databases, and a local Supabase CLI config is wired in. Direct DATABASE_URL usage is documented for migration execution, and new environment slots are reserved for anon-key testing, encryption, restore tokens, and rate limiting.

The schema content covers several clusters. An auth user lookup RPC, PDF conversion status tracking, and UUID foreign-key cleanup tied to billing address structural gaps. A security-and-lifecycle group adds row-level security policies for cross-tenant isolation, workflow sharing checks, an encrypted API key schema, soft-delete on user profiles, and scaffolding for an account deletion job.

As a disclosure PR, the intent is to make the data layer legible for AGPL compliance review rather than to introduce novel behavior upstream. The companion backend PR (#131) and the full umbrella PR (#127) give the runtime context for what consumes these tables.

So what Worth a look if you're evaluating migration tooling choices for a Mike fork - specifically whether `node-pg-migrate` fits your workflow versus a Supabase-native approach. The RLS policies and encrypted key schema are also useful reference if you're adding those capabilities to your own deployment.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?