Single-tenant → multi-tenant migration

The product ran as a single-tenant application with one shared database. Onboarding customers who needed their data physically isolated meant standing up and maintaining a whole separate deployment each time: slow, expensive, and hard to keep consistent.

• Introduced a tenant-resolution layer that identifies the current tenant per request and routes to the correct data source.
• Supported two tenancy models behind the same code path: shared-database (row-scoped) and isolated-database (one database per tenant).
• Built master-database management for tenant metadata: connection information, provisioning state, and configuration.
• Hardened data-isolation checks so queries can't cross tenant boundaries, including for background jobs that run outside a request.

• New tenants, shared or fully isolated, are configured through metadata instead of a new deployment.
• A single codebase and release pipeline now serves every tenancy model.