External interaction: per-branch (token-scoped) links so several people can each validate a parallel branch

The external interaction dispatcher (orchestra_interaction) keys its capability token on the instance, so one link drives whatever step the instance is currently parked on. That fits two cases well: a sequential chain of interactive waits, and a single wait offered to several people where the first to act wins (the same link emailed to several recipients).

It does not support parallel external interactions: an AND-split where several branches are each parked on their own external-interaction node, and a distinct validation link is emailed to a different person per branch, all of whom must act. Because the token is instance-scoped, every link is effectively the same credential, and the dispatcher resolves the parked step deterministically (the lowest-id token), so all recipients are routed to the same branch and the others cannot reach theirs.

Proposed solution

Make the link token-scoped (per branch): the capability targets a specific parked token, not just the instance, so each recipient link drives its own branch.

• Encode the token id alongside the instance id and expiry in the self-encoding capability token, validated the same way; the dispatcher loads that exact parked token and dispatches to its interaction.
• Carry the token id into the webform binding element so the resume handler resumes that token, not "the parked one".
• When a branch chains (one person has step1 then step2), re-mint the link for the next parked token in that lineage.
• Keep single-wait links working: a token-scoped link is a strict superset of the current instance-scoped one.

This is the deferred half of the parallel-interactive-wait findings from the pre-alpha4 audit. The audit fixes (MR !223) took the instance-scoped, one-interactive-wait-at-a-time path and documented the limitation; this issue is the follow-up to support true parallel, per-recipient interactions.