feat: add opt-in nested subagent delegation

[codesoda]

Summary

• add default-off allow_subagents custom-agent frontmatter
• optionally restrict targets with allowed_subagents and tighten the inherited depth cap with max_subagent_depth
• inject ownership-scoped Agent, get_subagent_result, and steer_subagent tools from the existing manager
• keep nested records out of top-level tools, RPC controls, lifecycle events, transcripts, and agent UI
• prevent pi-subagents from initializing another manager while constructing child sessions

Motivation

Some specialist agents own genuine fan-out work, but recursively loading the extension's normal orchestration tools gives child sessions top-level capabilities and reinitializes extension state. This makes delegation explicit per agent and scopes every nested operation to the owning parent.

The child-session async-context guard also avoids the per-spawn manager/interval activation described in #126.

Relation to #130

#130 enables the same broad capability by retaining extension-loaded tools below a global depth cap. This is an alternative implementation with a narrower contract: default-off, per-agent target restrictions, ownership-scoped controls, and custom tool injection without recursive pi-subagents activation.

Example

---
allow_subagents: true
allowed_subagents: scout, reviewer
max_subagent_depth: 2
---

With the default cap: main (0) → subagent (1) → nested child (2). Isolated agents never receive nested tools.

Testing

• npm run lint
• npm run typecheck
• npm run test (753 passed, 5 skipped)
• npm run build

[tintinweb]

thanks @codesoda for the pr. currently testing a rebased version of this. I like the shape. need to check if there are any side-effects.
one question I had is if we should keep allow_subagents or fold it implicitly into allowed_subagents: ... == nonzero. Also not sure if max_subagent_depth should be frontmatter or actually a config var.