A delivery token named no tenant, so any tenant's would do

A delivery token named no tenant, so any tenant's would do `DeliveryClaim` carries `tenant_id` and `VERSION` goes to 4. The field is first in the payload because everything after it is meaningless until the tenant is fixed: two tenants can hold assets with the same id, and until now the delivery path resolved which library to look in from configuration rather than from the token. **This closes a hole rather than only preparing for the refactor.** Delivery now compares the claim's tenant against the one the process serves, and disabling that comparison makes the new test return **302 — the asset served** — for a token naming a completely different tenant. Two deployments sharing a signing key produce exactly that token: a restored backup, a staging environment cloned from production. Before this there was nothing to compare, because the tenant was not in the signature at all. A v3 token now fails as `WrongVersion`, and this is the bump where that matters most. With no tenant field, a v3 payload read under v4 rules lands its `asset_id` where the tenant is expected and shifts every field after it — naming a plausible tenant it was never issued for, with a signature that covers the bytes rather than their meaning. Refusing costs nothing: a delivery token lives at most 24 hours, so every outstanding v3 token expires within a day of a deploy. The connector tests carry the tenant on `Site`, beside the id and the secret, because those three now have to agree — a token minted for the wrong tenant does not verify against the wrong library, it does not verify at all. **What this does not do**, and G22b in TASKS.md says so: delivery still reads through a pool pinned to one tenant's `search_path`, so the claim is checked against the configured tenant rather than used to select a library. One `damd` still serves one tenant. The shortcut that would make that quick — a pool per tenant — is refused by `single_tenant_pool`'s own documentation, so the remaining work is threading `TenantConn` through fifteen reads in the rights-enforcement path, which deserves its own session.