Story: Extract the user journeys that replace the ores.qt screens

Every component that had a UX in the removed ores.qt client has its user journeys documented, and every action its Qt screens offered is covered by a journey or recorded as dropped. This is the second pass of the sprint 26 mission; the UX is built from these journeys in the third.

The method is the User Journey Extraction Standard, written from the sprint 25 IAM journey work and extended with a pass over the legacy Qt screens. Each component runs it after its codegen clean-up story, because the coverage tables check each operation against the generated protocol.

• The User Journey Extraction Standard is written.
• Every component task below is DONE: its journeys are documented, its Qt actions all have a disposition, and its defects and gaps are recorded.

Only components that had screens in ores.qt run the standard. From the Qt tree: scheduler, workspace, workflow, iam, refdata, analytics, compute, reporting, synthetic, marketdata (with mktdata), dq and trading, plus the application shell. api holds shared widgets and is read with the shell; headless has no screens. The other components never had a UX.

The order follows the codegen clean-up order, so each component's journeys start once its clean-up is done. The application shell runs last, because it composes the other journeys.

• One story, one task per component. Journeys are grouped by topic, not by component, so a task's journeys may land in groups other tasks also use.
• The Qt screens are evidence, not a design. They are read so that no action a person had is lost without a decision; the journeys still start from the person's goal.

• The prototypes and the UX build, which is the third pass.
• The Wt client, which was removed with the Qt client.