Issue #3621006: Warn when a second tenant exists with no tenant resolver installed
Adds the runtime requirement proposed on the issue.
TenantContext::getCurrentTenant() falls back to the default tenant when no service tagged orchestra.tenant_resolver answers, and the only two resolvers ship in optional submodules. So a site whose configuration carries a second tenant without one has a tenant no request can act in: nothing can be created there, and the listings and access checks, scoped to the tenant in effect, hide whatever is already there.
OrchestraRequirements, which already carries #[Hook('runtime_requirements')], now also reports that: with more than one tenant and nothing tagged as a resolver, a warning counts the tenants out of reach and points at Orchestra Domain and Orchestra Server API. It stays a warning, and there is no tenant switch: the isolation is the intended model.
The hook reads the tenants through TenantContextInterface::getAllTenants() and takes the tagged resolvers as a second new argument, so a site that tags a resolver of its own counts like the submodules that ship one.
Note for the issue summary: tenants have no add, edit or delete form. The entity type declares only a collection link and the routing file adds only the retention and reading forms, so a tenant arrives with a config import, a custom module or a recipe, and the way back out is the configuration. The requirement and docs/multi-tenancy.md say it that way, and the message also says what removing a tenant takes with it, since OrchestraTenantHooks cancels its running instances and deletes every instance and scoped workflow.
Also here: the class docblock no longer describes the execution-mode gate the backlog check dropped, and the three new strings are in translations/fr.po.
Cost
The hook is reached only from SystemManager::listRequirements(), whose only production caller is the status report controller. Measured there on a site with three tenants: the check adds no query at all (the tenants come from the config cache) and 0.07 ms, against the 0.24 ms and one queue count the hook already spent.
Tests
AdvanceBacklogRequirementTest covered this hook class already, so it is extended and renamed OrchestraRequirementsTest. Two methods are new: the default tenant alone reports nothing while a second tenant is reported unreachable (the count of the tenants beside the default one, the severity, the two module names and the clause about what removal costs), and a resolver handed to the hook silences it while the backlog it is given still reports, so the absence is a decision rather than a hook that answered nothing.
DomainTenantResolverTest then asserts the same silence with a resolver really in the container, which is the only place the !tagged_iterator line in orchestra.services.yml is exercised at all.
Each was seen to fail against the code without it: dropping the resolver clause fails the resolver test, dropping the check fails the tenant test, and misspelling the tag in the service definition fails the domain test. The test-only changes job agrees, failing on assertArrayHasKey('orchestra_unreachable_tenants', ...).