Let the workflow own a webform interaction's post-submit behavior (chain steps)

When a webform is used as an interaction step, the workflow should own what happens after submit, not the webform's own confirmation settings. The same form can be a standalone collect in one workflow and a mid-chain step in another; only the workflow knows what comes next.

Feature

On a successful resume, return the party to the interaction's return URL (the dispatcher for a bearer step, the inbox for a task) instead of the webform's confirmation. The dispatcher then renders whatever the run parked on next: a read-only receipt, the next form, a message, or the run-complete page. This lets one workflow chain several forms (collect to a read-only receipt, form to form, form to payment to confirmation), with the same form reusable across steps regardless of its confirmation config.

Note on the original report

Investigation showed the dispatcher already renders a view-mode webform read-only correctly (now covered by a test); there was no rendering bug. The real gap was that after a bearer collect the party was not returned to the dispatcher, so the next bearer step was never shown. This reframes the issue from a bug to the feature above.

Implementation

The resume handler honors the return URL the interaction already passes, gated on a submission bound to an Orchestra instance (standalone webforms untouched) and only for an internal path. Follow-up to #3607035: Unify external interactions and user tasks behind one interaction plugin.