Bulk Cancel/Migrate on the instance list skip the tenant re-check (cross-tenant IDOR)

Problem/Motivation

The process instance list bulk actions "Cancel selected" and "Migrate selected to current" (added in #3607720) load the submitted selection with no tenant re-check, so a tenant-scoped operator can cancel or migrate running instances belonging to other tenants.

InstanceListForm::buildForm() scopes the rendered list to the current tenant for an operator without "administer orchestra", but the submit handlers read the selection straight from POST: selectedInstances() does loadMultiple($ids) with no tenant filter. The list widget is a core tableselect, whose value callback combines raw input without validating keys against the options, so a forged POST of arbitrary instance ids flows unchecked into submitCancel() and submitMigrate().

The single-instance operation routes are protected by InstanceTenantAccessCheck::instance, and the delete path is safe because InstanceDeleteConfirmForm::submitForm() re-filters by tenant, but the two new bulk handlers have no equivalent guard. Cancelling another tenant's running instance takes its live tokens and work items terminal (data-destroying); migrating rewrites its tokens and pins a new version.

Steps to reproduce

1. Two tenants; an operator holds only "access orchestra instances" (not "administer orchestra").
2. On the instance list, submit "Cancel selected" (or "Migrate selected to current") with a forged instance id belonging to another tenant.
3. The other tenant's instance is cancelled or migrated.

Proposed resolution

Re-apply the tenant filter inside selectedInstances() (covering cancel, migrate and delete-validation in one place): when the current user lacks "administer orchestra", filter the loaded instances to those whose getTenantId() matches the current tenant, mirroring InstanceDeleteConfirmForm::submitForm(). Add a kernel test that a tenant operator cannot cancel another tenant's instance via a forged selection.