Decide: should a steer that arrives after Stop start a new turn? #293

Found in the #262 live pass (test B, evidence).

Repro: run sleep 40 on a cheap model and open the same thread in a second tab. Press Stop in tab 1, then Ctrl/⌘+Enter (steer) in tab 2 about 250 ms later. The steer starts a new turn, which then replies.

Why: the client sends deliveryIntent: "steer" (packages/client-runtime/src/operations/commands.ts ~771). Once the interrupt has ended the run, resolveMessageDispatchIntent (apps/server/src/orchestration-v2/CommandPolicy.ts ~119) finds no active run and returns start_immediately. J5's kept committed-Stop guard (Orchestrator.ts, FORK.md temporary patch) only covers steer_active, so this is consistent with today's rule that "an explicit new message can start new work". It's pre-existing, not a merge regression.

Why it matters for J5: a person rarely hits this race by hand, but agents do. An A2A message delivered right after stop_agent or Stop can wake the agent that was just stopped. This is the case the Astra steer guard was about.

Decide: when a message sent as a steer arrives after a committed Stop on the run it targeted, should it:

• start a new turn (today)
• be refused with a visible reason
• be queued as held until the person resumes

Consider human steers and A2A delivery separately. Testing: this is hard to reproduce by hand, but it's deterministic in a server test: commit an interrupt, then dispatch a steer-intent message for that run.