Group workflows with an Application entity, and filter the task lists by it

Problem/Motivation

A task list can be narrowed to one workflow at a time. On a site running many of them, the workflows that belong together are the unit somebody wants to see, and nothing records that they belong together.

Done since this was filed

• #3624942: Expose a Workflow filter on the personal task lists, with the filter handler that already exists exposes a Workflow filter on both displays.
• #3624998: A task row is headed by a stored copy of the step name, so it stays in the source language and repeats the step below it heads a row with its workflow instead of a stored copy of the step name.

Resolution

An Application: a small configuration entity a workflow names by machine name, the shape orchestra_status already has. The name is then one record rather than a copy on every workflow, which matters for three reasons a plain value on the workflow cannot cover:

• It is translated once. A site creates these, so there is no catalog entry: the French is a language override on the record. Held on the workflow instead, the same word is translated once per workflow, and nothing keeps the copies agreeing.
• It is tenant-scoped, the way a status and a workflow are: empty means shared, a tenant id means visible only there. One tenant's applications have no business appearing in another's filter, which is the rule WorkflowFilter already applies to workflow labels.
• It is ordered, so the filter is not alphabetical by accident.

The two engines closest to this project group their models the same way: Camunda 8 calls the container a process application, Flowable an App. Both earn it by carrying deployment and permissions as well; this one carries the name, its translation and its scope, which is already more than a value can.

A workflow belongs to at most one application. Filtering stays a single choice rather than the disjunctive tag matching Airflow does.

What this adds

• The orchestra_application configuration entity and its schema, headless in the engine: orchestra_ui attaches the list, the forms and the link templates, as it does for a status.
• An application key on the workflow, exported and edited on its own tab beside Retention, Execution and Variables.
• An exposed Application filter on the personal task lists, resolving through the instance relationship the view already declares.

One rewrite comes with it: InstanceStatusProviderInterface says a running instance may be "a booking, a case, an application", where an application is something a person files. That sentence changes here, or the word means two things in one codebase.

Not part of this

Whether the lists should group rather than filter, and whether an application ever owns anything beyond its name.

AI-Generated: Yes (Claude Code was used to survey the shipped views, the workflow and status entities and the comparable features of other workflow engines, and to draft this issue summary and the change.)