HTTP routes and handlers for tenant management.

Provides REST API endpoints for:
- Tenant CRUD operations (list, get, create, update, delete)
- Tenant provisioning (schema creation, data seeding)
- Tenant activation/suspension

All routes require admin authentication (to be integrated with auth system).

HTTP routes and handlers for tenant membership management.

Provides REST API endpoints for:
- Inviting users to a tenant (POST /api/tenants/:tenant-id/memberships)
- Listing tenant members (GET /api/tenants/:tenant-id/memberships)
- Getting a membership (GET /api/tenants/:tenant-id/memberships/:id)
- Updating a membership role/status (PUT /api/tenants/:tenant-id/memberships/:id)
- Revoking a membership (DELETE /api/tenants/:tenant-id/memberships/:id)
- Accepting an invitation (POST /api/memberships/:id/accept)

Tenant provisioning service for creating PostgreSQL schemas.

This namespace handles the provisioning of tenant-specific database schemas
in PostgreSQL. It creates schema structures dynamically for new tenants.

Key Responsibilities:
- Create PostgreSQL schema for tenant
- Copy table structures from public schema
- Initialize tenant-specific data
- Validate schema creation success

Usage:
  (require '[boundary.tenant.shell.provisioning :as provisioning])
  (provisioning/provision-tenant! ctx tenant-entity)

Constraints:
- Only works with PostgreSQL (other databases ignored)
- Schema names must be valid PostgreSQL identifiers
- Provisioning is idempotent (safe to call multiple times)
- Does not copy data from public schema (only structure)

Run a function once per provisioned tenant schema, with that tenant's
search_path pinned for the duration (ZZP-86).

This is the background-job analogue of the HTTP `wrap-tenant-schema`
middleware: jobs that must touch tenant-scoped entity tables iterate every
provisioned `tenant_<slug>` schema and run their work inside each, so the
same connection-pinned tenant isolation applies as on the request path.
Without this, a job calling a repo with the pooled context runs under the
default `search_path = public` and only sees the (now empty) public tables.

HTTP middleware for multi-tenant request handling (imperative shell).

This namespace provides middleware for tenant resolution and database schema
switching in multi-tenant applications following the schema-per-tenant pattern.

Features:
- Subdomain-based tenant resolution
- JWT claim fallback for API access
- Database schema switching per request
- Tenant caching for performance
- Error handling for missing/invalid tenants

Based on: docs/adr/ADR-004-multi-tenancy-architecture.md

Per-tenant schema migration fan-out.

The platform `migrate` runs the migration set against the public schema. Each
tenant lives in its own `tenant_<slug>` schema, so the same migrations must
also run inside every tenant schema — otherwise a schema change lands in
public but not in existing tenants, and queries executed under the tenant
search_path fail with missing relation/column errors (the drift this fixes).

Each tenant run pins the JDBC connection's search_path to the tenant schema
via the PostgreSQL `currentSchema` connection property, so migratus creates
its own `schema_migrations` ledger inside that schema and applies DDL there.

Because migrations run once per tenant schema, tenant-run migrations must be
idempotent / tenant-scoped.