Task notifications link to whichever site caused the task, not to the one people work on

Problem/Motivation

TaskNotificationDispatcher::send() builds the inbox link with Url::fromRoute('orchestra_inbox.inbox')->setAbsolute(), so the host comes from the request that happens to be running. A task is normally created by the request that started the process, which on a multi-site or multi-domain install is the site the customer was using. The operator's a task is waiting for you mail therefore links them to the customer's site instead of to the back office. Cron-created tasks are worse: no request at all.

The same applies to a parked interaction step link, and, in the other direction, to a Notify node: author-composed content addressed to whoever started the run should render where they were, not where an operator happens to be validating.

Not every absolute link is wrong. InboxController's redirect runs inside a real inbox request, where the ambient context is correct.

Proposed resolution

Name the two places a notification can belong to, and let a site say what they mean.

• orchestra.notification_context with inWorkspace() for where people work, inOrigin() for where the process started, and currentOrigin() to stamp a starting instance. The shipped implementation is a no-op, so a single-front-end site pays nothing and its behavior is unchanged.
• orchestra_instance records an origin, an opaque string Orchestra never interprets, since by the time a message goes out the run may be advancing anywhere. A subprocess belongs where its parent does.
• Task and parked step notifications are built in the workspace; a Notify node in the origin.
• orchestra_domain gives both places meaning on a Domain Access site. Each tenant names the domains it lives on, on its own Domains form beside its retention settings: its public domain, where it receives people, and its workspace domain, where its operators work. It lives on the tenant and not on the domain records because it is not the inverse of the existing domain-to-tenant binding: several domains can point at one tenant, and a domain can serve several tenants. A tenant naming neither inherits the default tenant's, so a single-tenant site fills in one form. The switching itself is delegated to Domain Extras' domain_render_context.

Remaining tasks

Seam, instance field, three call sites, the Domain implementation and its form, kernel coverage, documentation and French translations.

User interface changes

One checkbox on the domain add/edit form, only with Orchestra Domain installed.

API changes

New service and interface. ProcessInstanceInterface gains getOrigin(). WorkflowExecutor and two notification dispatchers gain a constructor argument. Orchestra Domain adds one form and route per tenant. No change to the domain entity or its form.