[Feature]: Team-lead / work-handover support for the web (REST) hook provider

[tbrandenburg]

Pre-flight checklist

• I have searched existing issues and this is not a duplicate

Problem or motivation

The web (REST) hook provider (pixel-agents-hq#388, pixel-agents-hq#389) intentionally ships with no team extension — it can spawn/animate a single agent and transient sub-agents (subagentStart/subagentEnd), but has no concept of a team lead, persistent teammates, or handing work off between two independent agent characters. Anyone driving Pixel Agents purely over HTTP today has no way to visualize a multi-agent workflow the way Claude's Agent Teams users can.

Proposed solution

Add an optional TeamProvider to the web provider, mirroring claudeTeamProvider.ts but simplified for a provider with no transcript/config file to poll:

1. New wire events on the existing /api/hooks/web endpoint (no new HTTP routes): teamCreate, sendMessage, taskCreated, taskCompleted, teammateIdle — normalized to the existing subagentTurnEnd AgentEvent kind, same as Claude's TeammateIdle/TaskCompleted.
2. sessionStart gains optional team_name/agent_name/lead_session_id fields — since a REST teammate has no transcript for the runtime to discover team membership from, it needs to announce its own team membership directly on its own sessionStart, rather than being discovered via file scanning.
3. server/src/providers/hook/web/webTeamProvider.ts implementing TeamProvider: discoverTeammates, getTeamMembers, getTeamMetadataForSession, extractTeammateNameFromEvent, isTeammateSpawnCall — backed by an in-memory Map<teamName, members> instead of polling a config file.
4. agentRuntime.ts needs a file-free teammate-attach path. Today, onTeammateDetected → scanForTeammateFiles(...), which reads a JSONL transcript. A REST teammate has no file to scan, so attaching it needs to go straight from the wire-supplied team metadata instead — this is new integration code, not a tweak.
5. hookEventHandler.ts's subagentStart handling needs to check provider.team?.isTeammateSpawnCall(...) before falling into the existing explicit-id fast path (the one added in feat(server): add web (REST) hook provider pixel-agents-hq/pixel-agents#389), so a named spawn routes to teammate creation instead of a plain transient sub-agent.

How important is this to you?

Nice to have

Alternatives considered

• Do nothing: web-provider agents stay single/transient-sub-agent only. Fine for the primary curl-driven use case, but rules out visualizing any multi-agent orchestration built on top of the web provider.
• Piggyback on Claude's team model (write a JSONL-like config file for the web provider to poll): rejected — reintroduces the exact file-based discovery/polling complexity the web provider was built to avoid, for no real benefit given a REST caller can just state its team membership explicitly.

Additional context

Open design question that needs deciding before implementation, not left implicit: departure detection. Claude detects a departed teammate via periodic team-config polling (a member disappears from ~/.claude/teams/<name>/config.json). There's no file to poll for a REST-driven team, so we need one of:

• (a) an explicit teamMemberRemoved event — puts the burden on the caller to always announce departure (simple, but a crashed/killed script leaves a zombie teammate character), or
• (b) a stale/heartbeat timeout — more robust, more new code (a new timer + "last seen" tracking per teammate).

Rough scope estimate discussed prior to filing this issue: comparable to or somewhat larger than the base web-provider effort (pixel-agents-hq#388 + pixel-agents-hq#389) — new TeamProvider implementation, new wire schema fields, non-trivial agentRuntime.ts integration work (the file-free attach path), plus unit tests (provider + hookEventHandler) and an e2e spec covering lead→teammate spawn, message/handoff, and departure, comparable in size to the existing Claude @area:teams suite (7 tests today).

Builds on pixel-agents-hq#388 (provider registry refactor) and pixel-agents-hq#389 (base web/REST hook provider) — both prerequisites, not to be redone.