fix(email): resolve the email service per tenant on late-tenant routes; report Resend usage

[important-new]

Summary

Routes that learn their tenant only inside the handler (public booking, token-based signing, agent sign-in, repair-list share, concierge flows) were sending mail through the deployment-default email service. In multi-tenant mode that meant the platform sender, no Reply-To, platform branding, the tenant's own provider and template overrides ignored, and no usage metering. Replies landed in the platform mailbox instead of the company's.

This PR resolves the email service per tenant on those routes, adds a gate so the pattern cannot come back, and extends the Resend adapter to report quota usage and classify rate limiting.

What changes

Per-tenant email resolution

• New services.emailFor(tenantId, { recipientInitiated? }) and services.platformEmail() (server/lib/email/tenant-email-resolver.ts). emailFor reuses the service the DI middleware already built for that tenant, otherwise loads the tenant's config once per request. platformEmail() is the explicit deployment voice for sends that belong to no company (e.g. a global account's sign-in link).
• The eager, API-only config load in DI is unchanged: page renders re-enter the middleware chain many times and must not pay for a send they never make.
• Migrated send sites: public booking confirmation, remote signing confirmation and receipts, repair-list share email, and the two concierge flows (ConciergeService now takes a per-tenant resolver).
• The sign-completion workflow's email step now decides readiness from the resolved service, so a deployment where companies configure only their own provider still sends the signed-evidence message.

Outbound window, decided per call site

• The resolved tenant service carries the new-company outbound window (SaaS mode, platform-funded sends only). Messages that answer something the recipient just did (booking confirmation, signature confirmation) pass recipientInitiated: true and skip it. The decision is per call site, never per notification class, because the same class is also produced by automation rules for people who did nothing.

Gate

• lint:tenant-email (pre-commit) allows services.email only in an explicit list of files whose tenant is known before DI runs, each with its reason. It prints use and exempt counts on every run, reports stale allow-list entries without failing, and its spec proves it fails on a violating fixture. Limitation: it cannot see an instance handed to a constructor inside di.ts.

Resend adapter

• Send results carry optional usage (dailyUsed, monthlyUsed) parsed from the x-resend-daily-quota / x-resend-monthly-quota headers, on success and failure; missing or malformed headers omit it.
• A 429 rate_limit_exceeded is classified rate_limited with retryAfterSeconds from retry-after. Callers that do not know the new kind fall into the generic transient branch.
• probeApiKey reports reachable; "Test connection" answers 503 RESEND_UNREACHABLE instead of claiming validity when Resend cannot be reached. Save-time validation still ignores reachability.
• A 401 restricted_api_key is treated as a valid send-only key; listDomains counts verified domains only and distinguishes a send-only key from an account with none.
• Reading a header never throws when a fetch double has no headers object.

Impact by deployment mode

	Behaviour change
Self-host / single-tenant	None for sending. The fixed tenant was already resolved for every request, so the same service is used. The outbound window is SaaS-only and does not apply. Additions: the Resend usage fields and the clearer "Test connection" responses.
Multi-tenant, tenant with own provider (BYO)	Public/token/agent routes now send through the tenant's provider with its sender, Reply-To, brand and template overrides, and are metered to the tenant. Previously these routes used the deployment default.
Multi-tenant, platform-funded tenant	Same routes now use the tenant's sender identity, Reply-To and brand on the platform provider, and count against the tenant. Recipient-initiated confirmations are exempt from the new-company window.

No migrations, no new bindings, no new environment variables.

Tests

• Real middleware chain and routes in both modes with only fetch stubbed; assertions cover sender, Reply-To, brand and per-tenant metering. The multi-tenant cases failed before the change; single-tenant passed.

• Window regression tests cover a first-day tenant (confirmation delivered) and automation-produced mail (still held).

• Resend adapter: 34 new tests including header-less doubles; gate spec with violating and clean fixtures.

• SmsConsentBlock.test.tsx: the fixture was midnight UTC, so the date assertion passed only on UTC and east of it. It is now noon UTC; the component is unchanged. Unrelated to the email work, included because it made test:web fail on any developer machine outside UTC.

Notes for reviewers

• Type-aware eslint was not run locally (memory ceiling on the author's machine); relying on CI verify for it.
• package.json change is one script (lint:tenant-email).

🤖 Generated with Claude Code

https://claude.ai/code/session_01FDq9K9niRKMErgty3ca3DD