feat(run): single-loop max-steps salvage + enforce MaxToolCalls

Two gaps surfaced by a live fan-out smoke in a downstream host (mort):

1) A single-loop run that exhausts its step budget (ErrMaxSteps / ErrToolLoop)
   returned empty Output + a hard error, discarding all the reasoning it had
   produced — unlike the phased path, which already salvages a partial
   transcript and continues. Add opt-in single-loop salvage
   (Defaults.SalvageSingleLoopMaxSteps, default off): on budget exhaustion with
   empty Output, reconstruct a best-effort answer from the step narration
   (reusing salvagePhaseTranscript) and downgrade the run to a successful
   partial result. Off by default so a structured-output host keeps its clean
   hard error; an interactive host opts in.

2) RunnableAgent carried no tool-call ceiling — MaxIterations bounds STEPS, but
   one step can dispatch several tool calls, so a host's "max tool calls" cap
   had nowhere to land. Add RunnableAgent.MaxToolCalls (<=0 = unlimited,
   backward-compatible): the step observer counts executed calls and, once the
   cap is reached, stepCeilingOption forces the loop to exit; the resulting
   ErrMaxSteps is relabeled to the new ErrMaxToolCalls sentinel. Enforced
   single-loop only for now (phased is a follow-up). A cap hit is budget
   exhaustion, so salvage recovers its partial reasoning too.

isPhaseBudgetExhaustion becomes the shared isBudgetExhaustion (now also matching
ErrMaxToolCalls) so the phased and single-loop paths never drift, and the
RunStateAccessor now reports the real tool-call cap (was hardcoded 0).

Additive + backward-compatible: new optional DTO field, new opt-in Defaults
flag, new exported sentinel; unlimited/off reproduce prior behavior exactly. No
new dependencies (go mod tidy clean). Tests cover salvage on/off/no-prose, cap
enforcement + sentinel, cap+salvage, unlimited no-op, and cap-overrides-critic.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Q1eJh5NVR11z6RzyxLANMK

run/critic.go

@@ -110,17 +110,35 @@ func (b *criticBinding) recordToolStart(name, args string) {
 	}
 }
 
-// maxStepsOption returns the agent step-ceiling Option. With no critic it's a
-// fixed WithMaxSteps(base); with a critic it's a DYNAMIC WithMaxStepsFunc that
-// polls the handle each step (so the critic can raise a long run's budget),
-// falling back to base when the handle defers (MaxSteps() <= 0).
-func (b *criticBinding) maxStepsOption(base int) agent.Option {
-	if b == nil {
-		return agent.WithMaxSteps(base)
-	}
+// stepCeilingOption returns the agent step-ceiling Option, folding the run's
+// tool-call cap into the (optionally critic-driven) step ceiling. Priority:
+//
+//  1. tool-call cap hit (maxCalls > 0 && *toolCalls >= maxCalls): return the
+//     completed-step count so majordomo's `stepIdx < ceiling` check fails on the
+//     next iteration and the loop exits (the executor relabels the resulting
+//     ErrMaxSteps to ErrMaxToolCalls). Never returns <= 0 — majordomo would fall
+//     back to its own static ceiling — so a cap hit before any step completes
+//     clamps to 1.
+//  2. the critic's DYNAMIC ceiling, when a critic is bound and raises a long
+//     run's budget mid-flight (b.h.MaxSteps() > 0).
+//  3. the static base (MaxIterations).
+//
+// With maxCalls <= 0 and no critic this is exactly the old WithMaxSteps(base):
+// an unlimited-tool-call run is a true no-op. nil-safe on the binding (b == nil
+// skips the critic branch). toolCalls/steps are read live from the step
+// observer's counters (same goroutine as this poll — see executor.go).
+func (b *criticBinding) stepCeilingOption(base, maxCalls int, toolCalls, steps *int) agent.Option {
 	return agent.WithMaxStepsFunc(func() int {
-		if n := b.h.MaxSteps(); n > 0 {
-			return n
+		if maxCalls > 0 && toolCalls != nil && *toolCalls >= maxCalls {
+			if steps != nil && *steps > 0 {
+				return *steps
+			}
+			return 1
+		}
+		if b != nil {
+			if n := b.h.MaxSteps(); n > 0 {
+				return n
+			}
 		}
 		return base
 	})