Add orchestra_interaction: external-party interactive waits (customer-facing counterpart of orchestra_inbox)

Orchestra has a human-work layer for back-office operators: orchestra_inbox ships the orchestra_work_item entity, the user task type, assignment plugins, and the inbox UI. There is no equivalent for the other kind of human in a workflow: the external party (a customer, applicant, respondent) who is not a back-office user and is reached over a link, not an inbox row.

This proposes orchestra_interaction, the external-party mirror of orchestra_inbox. An "interactive wait" is a wait node that parks the workflow, shows the external party a configured interaction (a form, a payment, a message, a redirect), and resumes on their response.

Proposed pieces:

• An interaction NodeFeature (applies to parking task types) that tags a wait node with a customer-facing interaction descriptor, set in the modeler.
• An Interaction plugin type and manager. Generic plugins shipped here: message and redirect. Domain modules add their own (a webform step, a payment step, etc.).
• A public dispatcher controller addressed by instance id plus a capability-token HMAC, never the guessable id alone. It reads the parked node interaction descriptor and routes the visitor to the matching plugin, passing a return URL so steps chain with no landing screens, plus a generic signal route for customer-initiated outcomes (cancel, back).
• Optional notify: email the external party the tokenized link when the token enters the node (reusing orchestra_mail), for the off-site case where an assigned operator needs more information from the customer.

The symmetry with orchestra_inbox: the operator side is a work item claimed from the inbox (pull) via assignment plugins; the external-party side is a capability-token link to the parked instance (push) via interaction plugins.

This generalizes a booking-specific checkout dispatcher currently living in the Yoyaku project. The dispatching pattern is not booking-specific, so the generic mechanism belongs in Orchestra and any workflow can use it, with domain plugins living in the consuming project.

Scope: a new submodule, no engine changes. The NodeFeature, the plugin type, two generic plugins, the dispatcher, the capability token, an interaction-context value object, config schema, tests, and docs.