v0.8.63: Add a first-class sub-agent on/off switch

[Hmbown]

Problem

Users need a clear way to turn sub-agents on or off. Today the behavior is split across feature flags, CLI disable flags, and indirect runtime limits such as [subagents] max_depth = 0.

That is too easy to miss. A user who wants "no sub-agents this session" should not have to know implementation details.

Current state / evidence

• Docs mention feature flags and codewhale-tui --disable subagents.
• Config already treats [subagents] max_depth = 0 as blocking nested child-agent spawning.
• The model-facing agent tool can still be visible unless the runtime/tool registry has explicitly disabled sub-agents.
• Users need both a persistent preference and a per-session escape hatch.

Proposal

Add a first-class sub-agent enabled/disabled setting with a clear runtime command.

Possible shape:

[subagents]
enabled = false

and:

/config subagents off
/config subagents on
/config subagents status

The exact key name can change if it better fits the existing config model, but the user-facing behavior should be direct and discoverable.

Acceptance criteria

• Users can disable sub-agents persistently from the TUI.
• Users can re-enable sub-agents persistently from the TUI.
• A session-level disable path exists for temporary runs.
• When disabled, the model-facing agent tool is hidden or fails with a concise "sub-agents are disabled" error before doing any spawn work.
• /subagents or status/config output clearly reports disabled state.
• max_depth = 0, max_concurrent = 0, feature flags, and the new enabled flag have deterministic precedence with tests.
• Docs explain the difference between disabling all sub-agents and setting recursion depth to zero.

Release note target

For v0.8.63, this is a safety and control feature: users can opt out of delegation when they want a single-agent session.

[Hmbown]

Part of the broader config editability audit in #3303. This issue is the narrow v0.8.63 slice for explicit sub-agent enable/disable behavior.