Response cache for delivery reads, so a cache miss does not reach Postgres

Between the edge and Postgres there is nothing. A cache miss at the CDN, a cold edge in a new region, or a deployment without a CDN at all, and every request goes to the database.

A shared response cache, Redis or in-memory, keyed on tenant plus path plus query, absorbs that. It is the layer that makes a single origin serve a spike rather than fall over.

## Blocked

This is middleware, and a module cannot register middleware. See the module pipeline hook issue. Until that lands, this is either core or nothing.

## What it has to get right

**The key includes the tenant.** The tenant comes from the `X-Tenant` header first and the host second (`Infrastructure/Multitenancy/TenantResolutionMiddleware.cs`). A key that omits it serves one tenant's content to another, which is the same defect as #546 one layer down and is worse here because it is server-side and shared.

**The key includes the caller's visibility.** Delivery masks by sensitivity. Two callers with different access must not share an entry.

**Invalidation uses the same signal as everything else.** The publish event that drives the export, the build trigger and the CDN purge drives this too. Four different invalidation paths is three too many.

## Done when

- A second identical request does not reach Postgres, proven by counting sessions, not by timing.
- A request for tenant B never returns tenant A's bytes, proven by a test that would fail if the tenant were dropped from the key.
- Publishing invalidates within one second.

Start with the module pipeline hook issue, then inspect Infrastructure/Multitenancy/TenantResolutionMiddleware.cs and the publish event path. Confirm how tenant and caller visibility are available before choosing the cache layer. Done means repeated reads avoid Postgres, tenant data cannot cross keys, and publishing invalidates within one second.

Written by the indexing model from the issue text.