fix(core): reset steps for promoted prompts (#33452)

specs/v2/todo.md

@@ -26,14 +26,14 @@ through legacy `SessionPrompt.loop(...)`:
   tool results, and assistant output
 - a scoped `ToolRegistry` advertises definitions and the first permission-checked
   `read` built-in
-- local continuation reloads projected history and stops after 25 provider turns within one local drain activity
+- local continuation reloads projected history, and promoting new user input resets the selected agent's configured provider-turn allowance
 - concurrent resumes for one Session join one process-local run while different
   Sessions remain concurrent
 
 Prompt admission now uses a durable `session_input` inbox rather than immediate
-transcript projection. `steer` inputs coalesce into the active activity at the
-next safe provider-turn boundary. `queue` inputs form a FIFO of future activities
-that open one at a time.
+transcript projection. `steer` inputs promote at the next safe provider-turn
+boundary while the current drain requires continuation. `queue` inputs remain in
+a FIFO until the Session would otherwise become idle and then promote one at a time.
 
 Next reviewed slices:
 
@@ -53,16 +53,16 @@ Next reviewed slices:
 - add durable/clustered interruption, retries, and stale-owner fencing only as
   their slices become concrete
 
-### Deferred durable activity recovery
+### Deferred durable continuation recovery
 
 Do not infer that ambiguous provider work is safe to retry from an advisory wake.
 The first inbox-driven runner intentionally omits outer provider-attempt markers
 until they have a concrete consumer and a complete recovery policy.
 
-Design post-crash activity recovery as one explicit slice. It should model:
+Design post-crash continuation recovery as one explicit slice. It should model:
 
-- durable activity identity and settlement
-- queue-opener reservation and steer assignment
+- promoted input and projected-history state
+- queued-input promotion and steering assignment
 - provider-attempt preparation versus provider-dispatch ambiguity
 - required post-tool continuation across process loss
 - explicit `retry` and `abandon` decisions for unknown outcomes
@@ -70,6 +70,9 @@ Design post-crash activity recovery as one explicit slice. It should model:
 - retry budget, backoff, visible recovery status, startup discovery, and future
   clustered ownership fencing
 
+Do not introduce an enclosing durable execution identity solely to group these
+facts; a process-local Session drain has no durable transcript boundary.
+
 ## Plugin API design - James?
 
 We need to figure out how we want server plugins to work and what hooks are useful.