feat(team): implement multi-agent collaboration foundation — TeamManager, AgentMessageBus, SharedWorkspace, and WorkflowEngine coordinator

[Deepak-negi11]

Summary

Closes #76

The current architecture only supports single-agent and sub-agent workflows.
This PR introduces the foundational layer for team-based multi-agent
collaboration — a TeamManager, an isolated AgentMessageBus, a
SharedWorkspace, and a WorkflowEngine coordinator — wired into
AgentLoop via a new SummonTeamTool.

Architecture

User Message
    └── AgentLoop
          └── SkillsManager
                └── MultiAgentSkill
                      └── TeamManager
                            ├── AgentTeam (DevAgent, RevAgent, ArchAgent)
                            ├── AgentMessageBus (isolated event bus)
                            ├── SharedWorkspace (synchronized shared state)
                            └── WorkflowEngine (state machine coordinator)

New Modules

core/src/team/

File	What it does
manager.rs	TeamManager — orchestrates active teams by ID and memory paths
team.rs	AgentTeam — binds specialized agent roles (DevAgent, RevAgent, ArchAgent) with shared context
bus.rs	AgentMessageBus — isolated internal event bus for team communication, does not pollute primary output channels
workspace.rs	SharedWorkspace — synchronized resource for sharing artifacts, code patches, and design documents across all agents in a team
workflow.rs	WorkflowEngine — coordinator that tracks the state machine for multi-agent chains (e.g. Architect → Dev → Reviewer)

core/src/skills/

File	What it does
multi_agent.rs	MultiAgentSkill — encapsulates the logic of launching a full collaborative team instead of a single sub-agent loop

core/src/tools/

File	What it does
team_tools.rs	SummonTeamTool — LLM-callable tool that taps into MultiAgentSkill to delegate complex tasks to TeamManager

Modified Files

• core/src/agent/loop_.rs — Added register_team_tools() so the
  main AgentLoop can summon a full agent team via tool call. Wires the
  path: AgentLoop → SkillsManager → MultiAgentSkill → TeamManager
• core/src/lib.rs — Exported pub mod team and pub mod skills

Design Decisions

AgentMessageBus is isolated, not reusing crate::bus::MessageBus
The team bus is a private channel exclusively for intra-team events
(CodeReviewed, CodePushed, ArchitectureVoted). Reusing the global
MessageBus would leak team-internal events into user-facing output
channels.

Specialized agents use varied system prompts and tools, not distinct types
DevAgent, RevAgent, and ArchAgent are role configurations over a
standard AgentLoop rather than separate types. This keeps the agent
surface area small and avoids duplicating loop logic across three parallel
type hierarchies.

Incremental delivery — foundation only
This PR delivers the architectural skeleton. Full end-to-end task
delegation across a live team is a follow-up. The foundation is wired
correctly so subsequent PRs can add behavior without restructuring.

Testing

Test	What it covers
test_team_manager_builds_team	TeamManager correctly constructs a team with all three roles
test_agent_message_bus_dispatch	Messages published by one agent are correctly received by the other two mock agents
test_workflow_engine_transitions	Dry-run WorkflowEngine transitions through standard multi-agent states

Manual verification path:

# Invoke MultiAgentSkill via CLI tool
# Observe DevAgent, RevAgent, ArchAgent formation
# Verify shared workspace access and bus communication

Answers to Open Questions from #76

Question	Decision
Build WorkflowEngine natively or use mofa-sdk StateGraph?	Built natively in workflow.rs — keeps team orchestration self-contained and avoids coupling to SDK internals
Specialized loops via system prompts or distinct types?	System prompt + tool variation over standard AgentLoop — avoids type duplication
AgentMessageBus reuse global bus or isolated?	Isolated — team events must not leak into primary output channels

Related

• Closes improve arch for better implement multi-Agent collaboration #76
• Follows the same incremental delivery pattern as #343 / #570
  (MessageGraph contract first, execution second)
• WorkflowEngine in workflow.rs is intentionally compatible with the
  existing StateGraph execution model for future unification