Group-owned agent tasks: event-triggered, skill-based procedures with branching steps

[lollypoopdeck88]

What

Let a group, not a single user, own and submit tasks. A task is picked up from an event source and runs a predefined procedure made of existing skills. Procedures can branch on conditions and join back together.

1. Group ownership. A task belongs to a group, such as a directory/LDAP group or a KiroCrew team. Any member can submit, view, cancel or approve, depending on their group role. The task runs under a group credential stored in the vault, not a member's credential, so no single person has to be online.
2. Event-driven pickup. Sources are pluggable: a queue (SQS, or Lambda→queue), a webhook, or the existing cron. Delivery is at-least-once, and duplicates are dropped by task id. The runner is a headless, always-on host, not someone's desktop.
3. Procedures. A procedure is a versioned definition in which each step calls one existing skill with typed inputs and outputs.
4. Branching. Assumptions are listed below.

Branching assumptions

• A procedure is a DAG (directed acyclic graph). Steps have no loops and no cycles.
• Conditional branch: a condition on the previous step's structured output picks exactly one path. The first match wins, with an optional else.
• Fan-out: runs every listed branch in parallel, capped by a per-group concurrency limit. Steps inside a branch run in order.
• Join: waits for every branch that was taken. Skipped branches don't block it. The join receives {branch_name: output}, and the join step's own skill does the merging. Nothing is merged implicitly.
• Failure: a failed required branch fails the join. A branch marked optional passes null instead. Retries are set per step.
• Step state is saved so a run resumes after a crash without re-running steps that already finished.

Why

Today tasks, crons and workflows are tied to one user's identity and session. Team operations, such as triage queues and alert handling, need to keep running when that person is offline and need shared ownership and audit.

It also changes how teams use skills and agents:

• Skills become shared team assets. A group owns its procedures and the skills in them, so any member can improve a skill and every procedure that uses it picks up the change. Teams reuse proven skills instead of each person keeping a private copy.
• Teams can employ agents. A group can run agents as standing teammates that take work from the team's queue, follow the team's procedures, and keep going when no one is online.

Compatibility

Single-user task_run, workflow_run, cron and skill behavior stay unchanged. Procedures reuse skills as they exist today. Related: #9837.