v0.8.63: Expose editable sub-agent recursion and concurrency controls

[Hmbown]

Problem

Sub-agent runtime limits are implemented in config, but they are not first-class editable controls. Users cannot easily change the sub-agent recursion level or related launch limits from the TUI.

This makes sub-agents feel hardcoded even though the runtime already reads knobs like [subagents] max_depth and max_concurrent.

Current state / evidence

• Config::subagent_max_spawn_depth() reads [subagents] max_depth, defaults to the shared sub-agent/fleet recursion budget, allows 0, and clamps to the compile-time ceiling.
• Config::max_subagents() reads [subagents] max_concurrent before top-level max_subagents.
• Config::launch_concurrency() reads [subagents] launch_concurrency and supports a deprecated interactive_max_launch fallback.
• /agent [N] <task> exposes per-invocation recursive depth, but that does not solve global defaults or persistent user policy.
• Users should be able to inspect and edit these without hand-editing TOML.

Proposed controls

Expose a clear settings surface for:

• top-level max_subagents
• [subagents] max_concurrent
• [subagents] max_depth
• [subagents] launch_concurrency
• [subagents] api_timeout_secs
• [subagents] heartbeat_timeout_secs
• optional [subagents.models] role/type model defaults, at least as read-only if editing the table is too large for this slice

The exact UX can be /config subagents ..., a settings modal, or both, but the values must be visible and persistable.

Acceptance criteria

• Users can view current resolved sub-agent limits from the TUI.
• Users can set and persist [subagents] max_depth without manually editing TOML.
• max_depth = 0 is displayed as disabling nested child-agent spawning, not as an error.
• Values above the hard ceiling are rejected or clamped with a clear message.
• Users can set and persist the max concurrent sub-agent count.
• Users can set and persist launch concurrency separately from total max concurrency.
• Tests cover default, zero, high-clamp, and persisted reload behavior.

Non-goals

• Do not raise the compile-time recursion ceiling in this issue.
• Do not implement WhaleFlow/Fleet runtime wiring here.
• Do not change provider-aware model routing behavior except where needed to display role model defaults.

[Hmbown]

Part of the broader config editability audit in #3303. This issue is the narrow v0.8.63 slice for sub-agent recursion/concurrency controls.

[Hmbown]

Filed two companion issues that cover the behavior behind the numbers this issue makes editable:

• v0.8.63: Queue-and-drain admission for high-fanout Workflows (decouple total Agents from the concurrency window) #3318 — queue-and-drain admission for high-fanout Workflows. Today the spawn path hard-rejects once running_count() >= max_concurrent (crates/tui/src/tools/subagent/mod.rs:2300), so a wide fan-out gets a ToolError rather than queueing. The launch gate (v0.8.59: Sub-agent fanout planning can leave the TUI stuck in provider wait with no backpressure or recovery #3095) already paces starts; v0.8.63: Queue-and-drain admission for high-fanout Workflows (decouple total Agents from the concurrency window) #3318 is about admitting beyond the concurrency window and draining.
• v0.8.63: Token-budget governor for Workflows / high-fanout Agent runs #3319 — token-budget governor (spend pacing, not just count).

Suggest keeping this issue scoped to making the knobs (max_concurrent, max_depth, launch_concurrency, timeouts) viewable/persistable from the TUI, and letting #3318 own what the concurrency knob does under fan-out. The "concurrency = instantaneous cap" vs "total = population" distinction is worth reflecting in the labels/help text here.