Multi-tenancy: a single X-Tenant-Ids id should set the request tenant like the tenant path

[laugiov]

Context

A request can name its tenant through the path (/api/tenants/{tenantId}/...) or, on the regular path, through the X-Tenant-Ids header. The path sets the request's ambient tenant (TenantContext), which tables not yet under the v2 scope still rely on (Hibernate tenant filter, object storage paths, tenant-bound lookups). The header only feeds the TxCtx scope, so on the regular path those tables keep working in the default tenant while the v2 scope and the write attribution follow the header.

Proposal

When a request has no tenant in its path and exactly one id in X-Tenant-Ids, validate the caller's membership exactly as for the tenant path and set that tenant as the request tenant. Several ids, or no header, keep today's behaviour.

Definition of done

• A request on the regular path with one X-Tenant-Ids id behaves like the same request on the tenant path: reads, writes, object storage and tenant-bound lookups use that tenant.
• A non-member id is refused the same way as on the tenant path; anonymous and tenant-management endpoints keep their current handling.
• Several ids and no header are unchanged.
• Real-stack tests on both routes, including a table that is not yet under the v2 scope.

Advances #6393

[laugiov]

Deferred until after the v2 migration: this will be covered per table as they activate. See #7959 and #7972.