Prism roles: single model lists outside Worker, rename to Retry and Escalation, switchable Retry/Escalation #127

Outcome

Only the Worker role has easy/medium/hard lanes. Dispatcher, Retry and Escalation each read one ordered model list from the Prism snapshot. Correction is renamed Retry and recovery is renamed Escalation in user-facing text and the glossary. Retry and Escalation can be switched off in Prism; the runner then skips that ladder step (both off: a failed worker turn goes straight to a planner question).

Why

User decisions on 2026-09-25 (settings page review): lanes only matter for implementation; "correction" vs "recovery" misled, and "recovery" also means crash restart in the runner.

Contribution to the Objective

Keeps routing driven by the human's Prism settings (Mission: one policy, the most suitable eligible model) with fewer, clearer knobs.

Acceptance criteria

1. runner/t3snapshot.py reads a single list for dispatcher, correction (Retry) and recovery (Escalation); worker keeps three lanes. Old snapshots with per-lane lists for those roles still work (use the job's lane entry) for one release.
2. A snapshot flag enabled: false on Retry or Escalation skips that rung in _apply_ladder; tests for each off and both off.
3. GLOSSARY: Retry and Escalation defined (Escalation replaces the recovery-stage wording; "recovery" reserved for controller/crash recovery); policy notes and CLI/help text use the new names. Internal stage keys may stay correction/recovery to keep the snapshot contract stable; say so in the glossary.
4. Tests and proof pass.

Non-goals

Settings page UI (fork Issue). Planner role (removed from the page; the runner never read it). Reviewer stage (separate Issue).

Blockers

Snapshot shape agreed with the fork Issue for the Prism settings redesign.

Proof

python3 -m unittest discover -s tests, python3 -m compileall -q runner scripts tests, python3 -m runner.policy validate.