Multi-tenancy with PostgreSQL RLS, including the worker path

[FullFran]

Turn FeedPulse from a single-deployment application into a genuine multi-tenant
SaaS.

Approach

Use nestjs-tenant-rls-auth, which already exists and was extracted from a real
production SaaS: PostgreSQL Row-Level Security, JWT with refresh token rotation,
and AsyncLocalStorage-based tenant context.

This is deliberately not built from scratch. The library is the proven part.

Scope

• Integrate the library into the api runtime
• Add tenant_id to every domain table, with RLS policies enforcing isolation
• Propagate tenant context into BullMQ jobs. This is the hard part: the
  worker runs outside the HTTP request lifecycle, so AsyncLocalStorage
  does not carry across. The tenant must travel in the job payload and be
  re-established before any database access
• Per-tenant quotas: feeds monitored, alerts per day
• Per-tenant queue fairness so one heavy tenant cannot starve the others
• Tenant-scoped metrics and dashboards
• Integration tests that prove cross-tenant reads are impossible, including
  via the worker path

Definition of done

A test that fails loudly if tenant A can ever observe tenant B's data, through
the API or through a queued job.