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

The bulk generator created its rows without a tenant, so they fell back to the tenant field's default whatever realm the resource belonged to. The tenant is the realm boundary, so a season of slots generated for a second tenant answered to the wrong realm: hidden from the operators who generated them, visible to another tenant's.

What changed

• GenerateSlotsForm::submitForm() reads the tenant from the resource and carries it in each slot spec, so it survives the chunking into batch operations.
• batchCreate() stamps it on the slot, and each tier row takes it from the slot it provisions, which is how ResourceSlotsController and SlotTiersController already stamp the rows added by hand.
• A spec with no tenant still falls back to the field default rather than writing an empty tenant, which no realm would answer for.

I checked every other creation path for the same omission: BookingSlot::create() and BookingSlotTariff::create() appear nowhere else outside tests, and the two controllers already copy the parent's tenant. This generator was the only one.

Testing

The new test drives submitForm() and then runs the operations it queued, rather than calling batchCreate() with hand-built specs: the resource is where the tenant has to be read, and only the form knows it, so the existing tests could not have caught this. Run against the unfixed form it reports 'default' where 'opera' was expected.

yoyaku_ui kernel classes 3/3 green; phpcs and cspell clean; phpstan unchanged (its eight pre-existing new static() warnings are all in other files).