Add multi-tenant SaaS template

[PAMulligan]

Description

Create a multi-tenant SaaS template that extends the standard project setup with tenant isolation patterns — one of the most common enterprise API requirements.

Why

Multi-tenancy is the #1 architectural pattern for SaaS APIs. It requires careful design across database, middleware, and routing layers. A template that handles this correctly saves teams weeks of architecture work and prevents common security mistakes (tenant data leakage).

Acceptance Criteria

• Create a multi-tenancy middleware template supporting:
  • Schema-based isolation: Each tenant gets a PostgreSQL schema
  • Row-based isolation: Shared tables with `tenant_id` column
  • Both strategies selectable via configuration
• Generate Drizzle schema additions:
  • `tenants` table (id, name, slug, plan, created_at)
  • `tenant_id` foreign key on all resource tables (row-based)
  • Or schema creation/migration per tenant (schema-based)
• Create tenant resolution middleware:
  • Extract tenant from subdomain (`acme.api.example.com`)
  • Extract from header (`X-Tenant-ID`)
  • Extract from JWT claim (`tenant_id`)
• Add RLS (Row Level Security) policies for PostgreSQL
• Add tenant-scoped queries (all Drizzle queries automatically filtered)
• Include integration tests verifying tenant isolation
• Document trade-offs between isolation strategies
• CI passes

[PAMulligan]

👋 Flagging this as a great one for anyone looking to make a meaningful contribution to Nerva. Multi-tenancy is a high-value pattern and this issue is well-scoped, but it's large, so here's a suggested on-ramp if you'd like to pick it up incrementally rather than all at once:

Step 1 — Start with the row-based isolation strategy (shared tables + tenant_id). It's the simpler of the two and covers the most common use case.

Step 2 — Add the tenants table to the Drizzle schema and a single tenant-resolution path (the X-Tenant-ID header is the easiest to test).

Step 3 — Layer in tenant-scoped query filtering plus an integration test proving isolation.

Schema-based isolation, subdomain/JWT resolution, and RLS policies can each follow as separate PRs — no need to land everything at once. Happy to review early drafts and talk through trade-offs. If you'd like to take it, comment here and I'll assign you. First-time contributors very welcome. 🙌