Remove the committed-Stop patch and follow upstream (late steers and usage-limit resume) #343

Remove the committed-Stop patch and follow upstream

J5 carries a temporary in-place patch in apps/server/src/orchestration-v2/Orchestrator.ts that makes a committed Stop win over two automatic restarts:

• a steer the provider accepted before Stop, which upstream turns into a follow-up turn after it (register entry "A committed Stop wins over a racing steer");
• usage-limit auto-resume, added during the 2026-09-24 advance (register entry "A committed Stop also blocks usage-limit auto-resume").

Jackson (2026-09-28): drop both and follow upstream's implementation.

• Controlling a thread's turns is upstream's area. Upstream tracks this itself as TODO(interrupt-hardening).
• Both cases are races J5 doesn't design for (principle: repair beats edge-case machinery). Most agent messages queue rather than steer (D4), and upstream's Stop-holds-the-queue change (fix(server): preserve queued messages after usage limits pingdotgg/t3code#13877, on the V2 branch) covers queued ones. What remains is an Astra peer's steer that was already in flight when Stop was pressed. If a stopped agent wakes, the person stops it again.

Change:

• Remove the three hasCommittedStop conditions, the run_interrupt_request addition to readCommandProjection's turnItemTypes, and their tests ("Stop → usage-limit failure → automatic continuation refused", and the late-steer cases).
• Drop the patch from FORK.md's "Temporary in-place patches".
• In the register (docs/j5/product/upstream.md), move both entries to Retired. Add a line to D4's consequences: a stopped Astra agent can occasionally be woken by a peer steer already in flight.
• Related: Decide: should a steer that arrives after Stop start a new turn? #293 (closed on the same reasoning).