Issue #3624025: A webform step completed through the task doorway answers the confirmation page with a 403

Fixes a 403 served to the person who just did the work.

A webform bound to an Orchestra step through the identity (task) doorway saved the submission, completed the step and advanced the run correctly — and then answered with 403 Access denied.

Under the task doorway checkViewAccess() was checkCompleteAccess(), and once a step is completed nobody may act on it. So the gate refused everybody, the person who had just completed it included, on the page whose whole job is to say their submission worked.

A first submission never meets this: a start form carries no handle, and the gate returns on its first line when there is nothing to check. Every bound submit meets it the instant it succeeds. The bearer doorway is unaffected, because possession of a capability link authorizes viewing — which is why no existing test caught it, since they all bind with a capability token.

The fix

The identity doorway now asks the question it means. While a step is open, one nobody may act on is one they may not read: unchanged. Once it is finished, it asks who the step was rather than who may act on it — whoever it was offered to, or whoever completed it, may still be shown it, and to anybody else it stays a step they were never shown.

Who counts as having worked a step was already written down, in the rule that decides who may read a run afterwards (isAccountParticipant(), "whoever holds a step, and whoever completed one"). Both now share one condition builder, so read access and this gate cannot come to disagree, and the token-scoped question is an existence query rather than a load of every work item behind the handle.

Webform's inline confirmation page is also left alone by the handler, so it carries no submit to disable and no message about a step that has moved on.

Why not just the confirmation page

The first version of this keyed on webform's confirmation page. That fixes exactly one configuration. Only confirmation_type: inline sets that page; unticking Display confirmation when submission is updated, or choosing the message, modal or none type, leaves the visitor on the bound URL after a successful submit, where the 403 was unchanged. An operator toggling a checkbox brought the bug back.

Coverage

HandlerViewGateTest, the only suite that installs the task doorway — 11 tests. The ones worth reading:

• the assignee who completed the step reaches their confirmation, and reaches an ordinary build of it too (so the fix holds whatever the confirmation type);
• the completer who was never assigned it, and the assignee whose task another operator finished — the two halves of the shared rule, each pinned separately;
• a stranger is still refused the completed step, and an anonymous visitor is refused a step pooled to a role and then canceled, which is the one work item with neither an assignee nor a completer.

Every mechanism was proved in both directions by removing it and watching the named test fail: 6 of 6 caught.

Not in scope

Nothing is changed about what webform's own submission access allows: this gate governs the step, and the submission's answers remain webform's business.