feat(bot): bound concurrent subagents

[wutongyuonce]

Description

Background subagents were started with asyncio.create_task() without a capacity check, so repeated or parallel spawn calls could create unbounded concurrent LLM, sandbox, and external-tool work.

This change adds a process-local limit at the shared SubagentManager.spawn() entry point. It rejects excess spawns explicitly and reuses the existing completion cleanup to release capacity.

Human Involvement

• A human participated in the implementation or review loop
• This PR was generated entirely by AI agents without human participation in the loop

Related Issue

Closes #4613

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Test update

Changes Made

• Add bot.agents.subagent_max_concurrency, defaulting to 4 and validated as >= 1.
• Reject spawn calls when the manager is at capacity.
• Verify rejection at capacity and slot reuse after task completion.
• Document the setting in the English and Chinese Bot READMEs.

Testing

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have tested this on the following platforms:
  • Linux
  • macOS
  • Windows

PYTHONPATH=bot:. uv run --no-project --with pytest --with pytest-asyncio --with pydantic-settings --with loguru --with pyyaml --with httpx --with fastapi --with json-repair --with litellm --with ruff -- python -m pytest --noconftest -o addopts='' -q bot/tests/test_subagent_skills_context.py bot/tests/test_channel_delivery_metadata.py

Result: 19 passed. Ruff check, Ruff format check, and git diff --check also pass.

Checklist

• My code follows the project's coding style
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published

Screenshots (if applicable)

Not applicable.

Additional Notes

I chose 4 as a conservative default and implemented it before waiting for a capacity decision so the trade-off is concrete. I am happy to adjust the default if maintainers prefer another value.

This intentionally rejects excess requests instead of adding a queue. A queue can be added later if callers need deferred execution semantics.