Regional DB Split

What this PR is

This PR ("Regional DB Split", branch merge-train/regional-db-schema) is a foundational architecture change to Dentolize's backend. It is not a new clinic-facing feature — clinics keep using the same web app, mobile app, and workflows they already know. It is a rebuild of how Dentolize stores and serves data so the company can run separate database regions (for example, one in the EU and one in Saudi Arabia) instead of a single shared database for every clinic worldwide.

It touches 437 files and adds roughly 59,500 lines across the monorepo — new services, new database schemas, new deployment tooling, and an extensive migration/verification toolkit. This is infrastructure work in service of data residency, scale, and resilience, with a thin but real layer of user-visible change in login and in the internal admin dashboard.

Why it exists

Dentolize runs one shared PostgreSQL database today. As the product expands into new markets — starting with Saudi Arabia — that single database becomes a liability on two fronts: data residency (some customers and regulators expect clinic data to stay in-region) and blast radius (a schema change, a slow query, or an outage anywhere affects every clinic everywhere). This PR splits the system into:

• One global database holding the small set of things that must be shared everywhere: admins, referral partners, region directory, and the routing tables that say "this email/company lives in region X."
• One regional database per region (e.g. EU-1, ME-1) holding everything else — companies, patients, appointments, invoices, inventory, and so on — fully isolated per region.
• A new global Auth Server (packages/auth-server) that fields "which region is this user/company in?" lookups and routes clients to the correct regional API before they ever authenticate.
• A company-region migration toolkit that can move a single clinic's entire dataset — rows, uploaded files, routing — from one region to another with almost no downtime, so existing clinics can eventually be moved onto the new architecture without disrupting them.

See Architecture: Global vs. Regional Split for the technical shape of the split, and DEPLOYMENT.md / scripts/MULTI_REGION_PLAN.md / scripts/GO_LIVE_RUNBOOK.md in the repository for the operational plan this PR is building toward.

What actually changes for people

• Every login now does a region lookup first. Before checking a password, the app asks the Auth Server "what region is this account in?" and connects to that region's API. This is mostly invisible, but it's a new step in a code path every user hits every day. See Region-Aware Login & Multi-Account.
• Users can now hold multiple logins side by side and switch between them from the profile menu — including logins that live in different regions — without a full logout. This is a genuinely new capability, not just plumbing. See the same page.
• The internal admin dashboard gains a region selector on cron jobs and Redis-key tools, and its underlying queries now fan out across every region instead of hitting one database. See Admin: Cross-Region Controls.
• Everything else — patient records, appointments, invoicing, insurance, WhatsApp — behaves the same. The regional Prisma schema is auto-generated from the existing monolith schema, so the data model itself is unchanged; only where it's hosted has changed.

How to read this walkthrough

Start with Walkthrough for real screenshots of the login and admin changes. Then read the feature-breakdown pages for the technical detail (with file:line references into the PR), or jump straight to your team's page under By team for a role-specific take. Glossary & Data Model has definitions for the region/migration vocabulary this PR introduces.

This is unreleased work. Nothing described here is live for clinics yet — production rollout follows the phased runbook in scripts/GO_LIVE_RUNBOOK.md, migrating one region at a time.