Database-per-tenant setup

# TenancyJS Integration Agent - Express 5 + TypeORM, database-per-tenant (PostgreSQL)

You are an integration agent. Wire fail-closed, database-per-tenant multi-tenancy into THIS Express +
TypeORM app on PostgreSQL with TenancyJS, integrating with whatever already exists - do NOT assume a
greenfield app. Execute steps in order; after each, verify it applied before continuing. If a step does
not apply to this repo, say so and adapt. Do NOT invent or assume API names, versions, or enum values, and never assert them from memory (your training data may be stale - library versions change). Verify against the real thing FIRST, then claim: `npm view <pkg> version` for a version, and the installed package's own types (in node_modules) or the linked docs for exact signatures and literal option values (e.g. the strategy is the string `"rowLevel"`).

Source of truth:
- https://tenancyjs.pages.dev/docs/adapters/typeorm
- https://tenancyjs.pages.dev/docs/strategies/database-per-tenant
- https://tenancyjs.pages.dev/docs/guides/provisioning/typeorm
- https://tenancyjs.pages.dev/docs/integrations/express
- https://tenancyjs.pages.dev/docs/guides/testing-isolation

## Step 0 - Assess the app (change nothing yet)
- Report the Node version (abort if < 24), the `express` and `typeorm` versions, and confirm PostgreSQL
  and the `pg` driver are available. If this is not an Express + TypeORM + Postgres app, stop.
- Inventory the TypeORM entities: list every entity and mark each as tenant-owned or global/central.
- Find how the current user is determined per request (`req.user`, session, JWT) - the `authorize` hook
  will need it.
- Detect any EXISTING tenant concept (a `tenantId`/`orgId` column, a workspaces/orgs table, or existing
  per-tenant databases). If one exists, REUSE it - do not add a parallel one.
- Summarize what you found + the integration plan, and confirm the ISOLATION STRATEGY with the user:
  database-per-tenant (this page) vs row-level vs schema-per-tenant. If database-per-tenant does not
  fit, point them to https://tenancyjs.pages.dev/docs/strategies/choosing and stop.

## Step 1 - Install
`npm install tenancyjs-core tenancyjs-adapter-typeorm tenancyjs-integration-express tenancyjs-identifiers typeorm pg`
Verify the install succeeded before continuing.

## Step 2 - Placement on the tenant record
Each tenant row must carry a `databaseKey` - an opaque handle to its database, NEVER a URL or
credentials. The store's `find(identifier)` returns `[{ tenant: { id, databaseKey }, status }]`.
Verify the field exists and is opaque before continuing.

## Step 3 - tenancy.ts
- One exported `TenancyManager<Tenant>`.
- A `landlord` TypeORM `DataSource` for central work.
- A `createInitializedDataSource(databaseKey)` factory that returns a fully INITIALIZED tenant
  DataSource registering EVERY entity (call `.initialize()` before returning it).
- The adapter in database-per-tenant mode:
  ```
  const tenancy = createTypeOrmTenancy({
    manager,
    dataSource: landlord,
    strategy: "databasePerTenant",
    // List EVERY existing tenant-owned entity here; only add a new example entity if the app has none yet.
    tenantEntities: [
      { entity: Post, table: "posts", tenantProperty: "tenantId", tenantColumn: "tenant_id" },
    ],
    connection: (tenant) => ({
      key: tenant.databaseKey,                       // opaque; never a URL
      create: () => createInitializedDataSource(tenant.databaseKey),
    }),
  });
  ```
  ALWAYS provide a dispose (`close`/`destroy`) so the cache evicts idle tenant DataSources. Never use
  the landlord DataSource inside a tenant scope.
- A `TenantResolutionChain` (HeaderTenantResolver + the store above).
Verify the file type-checks before continuing.

## Step 4 - Express wiring
`app.use(createExpressTenancyMiddleware({ manager, resolver }))`; add an error handler for
`ExpressTenancyResolutionError` (400/404/500). Inside a request, query INSIDE a scope:
`tenancy.run((client) => client.repository(Post).findBy({}))`. Verify before continuing.

## Step 5 - Provision each tenant's database
Implement the provisioner hooks (see the TypeORM provisioning recipe): `provision` runs
`CREATE DATABASE "tenant_x"` on a privileged admin connection (NOT in a transaction); `migrate` runs
your TypeORM migrations against the tenant database; `deprovision` drops it. Then:
`npx tenancyjs-cli tenant create acme --set databaseKey=tenant_acme` -> `npx tenancyjs-cli tenant provision acme`
-> `npx tenancyjs-cli tenant migrate acme`. Verify each tenant's database exists and is migrated. If the
app already has existing tenants, provision and migrate a database for EACH of them before cutover - do
not leave an existing tenant without a database.

## Step 6 - Central work
Cross-tenant / admin work runs against the landlord explicitly via `manager.runInCentralContext(...)`.
Never run tenant-aware queries with no scope. Verify before continuing.

## Step 7 - Verify isolation (an isolated test - it does NOT touch app data)
Two TEST tenants in two TEST databases (never real app tenants), same primary key: write a row under
each, assert querying as A never returns B's row, and that a tenant query with no scope THROWS. Follow
the testing-isolation guide.

## Step 8 - Roll out + verify
- `npm run build`, boot the app, run the two-tenant test. Report every file changed and any issue.
- Existing app: provision + migrate a database for every existing tenant before cutover, then roll out
  incrementally - scope routes behind the middleware, keep admin/cross-tenant work in
  `runInCentralContext`, and treat any thrown unscoped-access error as a route you still need to scope.