Webform handler seeds start and resume variables after the synchronous inline drain, so first-segment routing sees unset values

The Webform interaction handler seeds a started run's variables (submission id, submitter uid, value map) AFTER WorkflowEngine::start() returns, and writes the resubmitted value map AFTER resume() returns. Under the shipped default synchronous execution mode both start() and signal() advance the run's segment inline before they return, so those writes land too late: the run's first segment, and the segment after a resumed step, route on unset or stale variables.

Concretely, a workflow whose first segment has a gateway routing on values.priority (a submitted field) takes the wrong branch, because the value map is still empty when the gateway evaluates. The same happens after a resumed step that routes on the resubmitted values. InstanceStartedEvent is also dispatched with an empty variables array. The defect is silent: the variables do exist by the time anyone inspects the instance, so a post-mortem looks correct.

Why it was not caught

Every existing test workflow parks immediately after start and routes only on the task result, which travels inside the resume, never on the value map in the first segment, so neither the test suite nor the earlier audits exercised it.

Fix

• Start: pass the variables into start(), which seeds them (and dispatches InstanceStartedEvent with them) before the inline drain, instead of seeding after it returns.
• Resume: write the submission id and value map before resume(), so the inline advance of the next segment sees the fresh values. The result still travels inside the resume.
• Two kernel regression tests route on the seeded and resubmitted value map in the first segment and after a resumed step; both fail on the old ordering and pass with the fix.

Found by a release-candidate audit of the changes since 1.0.0-alpha8. Affects the default synchronous execution mode.