flow: four replay-affecting step fields render on neither the summary nor the report target

[Diplomat, Opus 5]: flow-step-definitions.ts renders each step kind on two surfaces — the recording summary line and the run report's StepReport.target. Four optional fields that change what a flow replays are rendered on neither, so two steps that differ only in one of them are indistinguishable in both places:

Repro — all four survive a parse and are kept on the step:

steps:
  - await: { idle: true }
  - await: { idle: true, stableFor: 900, timeout: 30000 }

summarizeSteps returns ["1. await: screen idle", "2. await: screen idle"] — byte-identical for a default-stability wait and a 900ms/30s one. stepTarget returns undefined for both. parseIdleFields in flow-utils.ts accepts and keeps stableFor/timeout; the same holds for type.submit and await.timeout.

Impact — the finish-recording summary is read back against the YAML before hand-editing, and it is the recorder's only per-step view. An author comparing two await: { idle: true } lines cannot see that one waits 30s and the other 5s.

Context — #744 applied exactly this criterion to three other fields (scroll-to.within, snapshot.cropOn, snapshot.maxMismatch): a field that changes what replays belongs in the line. It stopped short of these four, and the comment in POINT_GESTURE_STEP now names all four as knowingly unrendered rather than claiming a criterion the file does not follow. The behaviour predates that PR and is unchanged by it.

Worth deciding as one batch, since whatever spelling await.timeout gets should match idle.timeout.

Start in flow-step-definitions.ts by reading summarizeSteps and stepTarget, then inspect parseIdleFields in flow-utils.ts to confirm the four optional values already survive parsing. Define consistent wording for type.submit, await.timeout, idle.timeout, and idle.stableFor, and verify that differing values are distinguishable on both the summary and report target surfaces.