Generated slots and their tariff rows take the literal default tenant instead of the resource's

The bulk slot generator creates its rows without a tenant, so they take the tenant field's default, which is the literal default tenant, whatever realm the resource belongs to.

In GenerateSlotsForm::batchCreate() the slot is created from a values array holding resource, start, end, opens_at, status and published, and each tier row from slot, tariff and quota. Neither carries tenant. Every other creation path copies it from the parent explicitly: the resource slots controller sets it from the resource, the slot tariffs controller from the slot, the placement inventory controller from the venue, and the booking manager from the slot.

Why it matters

The tenant is the realm boundary. The access handler compares an entity's tenant against the current one, and listings narrow their queries the same way. So on a site with two tenants, slots generated for tenant B are stamped A, which means the operators of B cannot see what they just generated, while the wrong tenant can. The rows are not merely mislabelled: they answer to the wrong realm.

It is invisible today because every site running this is single-tenant, so the default is accidentally correct. That is exactly the kind of bug that surfaces the day a second tenant is added, with a season of slots already generated.

Fix

Stamp the tenant from the resource in the batch, the same way the single-slot path does. Worth checking the whole file for other create() calls in the same shape, and worth a kernel test that generates for a resource in a non-default tenant and asserts both the slot and its tier rows come out in that tenant, since no existing test would have caught this.