Add, edit and delete tenants from the Tenants list

Orchestra ships multi-tenancy but no way to manage a tenant. The orchestra_tenant entity type declares only a collection link, so the Tenants list at /admin/config/workflow/orchestra/tenants shows the tenants and reaches the per-tenant Retention and Reading forms, and nothing else: there is no add form, no edit form and no delete form. A tenant therefore arrives with a config import, a custom module, a recipe, or core's single-item import form at /admin/config/development/configuration/single/import, and its label can only be changed the same way.

Removal is the worse half, because the obvious command is the unsafe one. Taking a tenant out through the entity API (a config import that drops the file, or $tenant->delete()) runs OrchestraTenantHooks: it cancels the tenant's running instances, then deletes every instance scoped to it, cascading to tokens, variables and incidents, and the workflows scoped to it, and it refuses the default tenant outright. A raw config delete (drush config:delete orchestra.tenant.acme) does none of that: nothing in core forwards a raw config write to the entity API, so the runtime rows are orphaned, and drush config:delete orchestra.tenant.default walks past the access handler, the list builder and the predelete guard alike, leaving every request to throw TenantException.

Proposed: give the entity type add-form, edit-form and delete-form links with a plain ConfigEntityForm and core's delete confirmation, plus an "Add tenant" local action on the collection. The delete confirmation is also the natural place to say what deleting a tenant takes with it, which is currently written down nowhere the person doing it would see.

The machine name stays immutable once created, as for every config entity, so the edit form offers the label and the weight; retention and reading keep their own forms.

AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it before posting; there is no code on this issue yet.)