The manager's tenant task list names each task by the copy stored when it was created, so it stays in that language

Problem/Motivation

#3624998 fixed this on the personal task lists and left it on the manager's one. The Orchestra tenant tasks (manager) view at /admin/orchestra/dashboard/inbox shows a Task column rendered by a plain field handler on the work item's stored label column. That column is a copy of the step name written when the task was created, so on a French site whose workflow is translated the manager reads Validate submission where the assignee's own notification says Valider la soumission.

The engine already answers this correctly: WorkItemManager::getLabel() reads the live node label in the viewer's language and falls back to the stored copy only when the node is gone. The task notifications use it. No views handler does, so any view built on the work item's label field has the same fault.

Proposed resolution

• Add an orchestra_work_item_label views field that renders WorkItemManager::getLabel(), warming the page's tokens, instances and workflows in one load each so it costs no query per row.
• Make it the handler of the work item's label field in the views data, the way the state field already gets orchestra_work_item_state, so a view a site builds from that field gets the translated name too.
• Point the shipped orchestra_inbox view at it.

The stored column stays on the entity: it is the fallback getLabel() needs, and it remains sortable.

Two more faults of the same list were found while fixing it, and are fixed here too:

• Every Orchestra list that names workflows, steps or statuses is cached on its entity type's list tag, and a translation is saved as a language override that invalidates only the translated entity's own tag. So a list cached before a translation kept the old wording for readers of the language just translated. A subscriber now invalidates the list cache tags of an Orchestra config entity type when one of its entities is translated, which fixes the Task column, the My tasks heading, the Waiting on column, the trace's step names and the status tags at once.
• The Task column was cached on the token list, which every step of every run on the site invalidates, so the manager's list was thrown away whenever anything ran. It is cached on its own rows' tokens instead.

The same list's Process column rendered empty for every reader, the site administrator included, and so did the tokens view's Process and the trace's From token. They used core's entity reference label formatter, which asks the referenced entity whether it may be seen, and the instance and token entities have no access handler, so they answer no to everyone. A new orchestra_instance_label views field prints the instance's name, linked to its read-only page only where that page's own access check admits the viewer; the trace shows the parent token's id.

On French sites the same lists also read wrong in two more ways, fixed here too. Core translates a bare "Status" with the word this project uses for "State", so the status and state columns side by side were headed the same: every workflow-authored "Status" now carries the Workflow translation context, and the five task states carry Task, with new French wording (À traiter, Prise en charge, En cours, Traitée, Annulée). And Gin wraps every views field keyed status in its own published/unpublished marker, so the status tag was drawn as a pill inside a pill: the state columns now render through a template of their own, offered just ahead of that one.

Remaining tasks

None beyond the change and its test.

AI-Generated: Yes (Claude Code found this in a pre-release audit of the module, drafted this issue summary, and wrote the change and its tests on the merge request.)