Issue #3622165: Bulk delete, Start and the three completion surfaces act or report without asking the engine

Three admin surfaces that either acted on a run without asking whether they may, or reported a change without reading whether it happened.

• Delete process (orchestra_vbo) refuses a running instance from access(), so Views Bulk Operations lists the row with the reason and still processes the rest of the selection; execute() re-checks the state before deleting. EntityInterface::delete() runs no access check, so the action was deleting running instances and cascading through their tokens, variables, incidents, work items and subprocess children.
• The Start operation on the model list is offered only when DefinitionResolver::getStartRefusal() returns NULL, and the controller asks the same question, catches the race, and warns with the refusal instead of letting a LogicException escape as a 500.
• The inbox controller, the inbox task form and the attached-content task screen read the boolean WorkItemManager::complete() returns and warn that nothing was recorded, the way the pull-side surfaces do since #3621881.

Kernel coverage for each defect, plus the French catalogs for the five new messages and the bulk-actions documentation.

Closes #3622165.

---

Audit round on this MR (six passes over the diff, each finding turned back on its own fix):

• The bulk delete asked the run's state before the permission. A forbidden result wins the conjunction and its reason shadows the other side's, so a user who simply lacked administer orchestra was told to go and cancel a run. The state is now asked only of somebody the permission admits, and the permission reason is pinned by its own test.
• The completion surfaces named a cause they cannot know. complete() answers FALSE both for a task somebody else finished, which moved the run on, and for one whose lock could not be taken, which left it waiting - and the lock case is what these tests actually exercise. All four surfaces now state that nothing was recorded and send the reader to look, without asserting which happened. That includes orchestra_vbo_inbox's Complete task, which reported "it was already finished" for both.
• The stale-outcome case got its own message on the two form surfaces. complete() throws \InvalidArgumentException when the workflow was edited while a form sat open, and on the attached-content screen the entity is already saved by then, so it answered a successful save with a 500. It is caught, and the reviewer is told the answers the step takes now rather than to reload a list that still shows their task.
• WorkItemManager::complete()'s @return documented only "already terminal", which is the reading that makes announcing success look harmless. It now names the lock-refused and task-gone cases too.
• Nothing exercised OrchestraUiController::start() on the accepted path, so a refusal check that refused everything would have passed. Both halves now assert their redirect target.