Steps: propagate step result State to later steps #346

Context

The step handler contract introduced in #324 lets a handler return @{ Changed; Data; State }.
State is reserved for values that later steps of the same run can consume, but the engine currently only
validates it (must be a hashtable) and passes it through to IdLE.StepResult.State. Nothing reads it.

IdLE.Step.Mailbox.GetInfo already returns State = @{ Mailbox = ... }, so the output exists but cannot be
used by downstream steps or conditions.

Goal

Define and implement how step State becomes available to later steps, keeping planning deterministic and
workflows data-only.

Open design questions

• Addressing: Which path do workflows use (e.g. {{State.<StepName>.<Key>}} in templates, State.* in
  Condition / preconditions)? How are step names with spaces or duplicates handled?
• Resolution time: Templates are resolved at plan time today. State only exists at execution time, so
  references to it need deferred (execution-time) resolution. Which places support it?
• Validation: Can planning check that a referenced step exists and runs earlier? Should steps declare their
  State outputs in the metadata catalog (like WithSchema) so references can be validated and documented?
• Failure and skips: What does a reference resolve to when the producing step failed, was skipped
  (NotApplicable) or did not run?
• OnFailure steps: Do they see State from primary steps?
• Security: State must stay data-only (no ScriptBlocks) and must not carry secrets into events or exports.

Acceptance criteria

• Documented contract in docs/extend/steps.md (and workflow docs for the reference syntax)
• Engine support with tests (happy path, missing/failed producer, ScriptBlock rejection)
• At least Mailbox.GetInfo usable as a producer in an example workflow