dos-dispatch-looplisted

# dos-dispatch-loop — the generic dispatch⇄replan cadence > **The unattended plan-and-ship loop.** It runs `/dos-dispatch` repeatedly and > falls to `/dos-replan` when a lane drains, stopping on a typed, kernel-decided > condition (not a prose guess). The stop/continue logic is the kernel's > `loop_decide.decide` — the loop carries counters, the kernel decides. Several > loops on disjoint lanes run in parallel, each holding its own lane lease. The stop conditions are the kernel's, in one place: 1. **iteration cap** — reached `max_iterations` (default 10). 2. **drained-twice** — a DRAIN after a *productive* `/dos-replan` that itself followed a DRAIN (the lane is genuinely exhausted). 3. **consecutive-unclear** — the dispatch subprocess is failing systematically. 4. **rate-limited** — a usage window is exhausted (don't burn launches). 5. **launch-failed** — a subprocess never started. 6. **pick-held-invariant** — the next unit is held ONLY by a reason a re-dispatch cannot change (draft-class / operator-gated / soak-open / dependency-unmet); re-dispatching it would re-block identically, so honest-STOP + surface the hold. 7. **pick-cooldown** — the next unit was attempted-and-didn't-move inside its cooldown window AND nothing fresher is offerable; re-dispatching it would re-storm a known drain (the ~5%-shipping re-pick loop the bare loop hit). 8. **not-ratcheting** — the OUTER RATCHET (docs/351): the loop has run too many iterations in a row with no *witnesse