feat(github): orchestrate labeled parent issues across sub-issues and blockers

Component

CDK GitHub adapter, orchestration

Describe the feature

When a GitHub parent issue is label-triggered and has native GitHub sub-issues or dependency relationships, ABCA should orchestrate the child work as a dependency-aware graph instead of running the parent as one large task.

This mirrors Linear parent/sub-issue orchestration and the Jira parity issue: one parent issue represents the epic, child issues become executable tasks, dependencies determine release order, and the parent receives a rollup comment when the graph settles.

Use case

GitHub Issues now supports native sub-issues, and teams also express dependencies through issue relationships/prose. A user who already broke an epic into sub-issues should be able to label the parent and have ABCA run the child graph in reviewable pieces.

Proposed solution

Add a GitHub graph-discovery path to the GitHub Issues processor:

• On a parent label trigger, read native GitHub sub-issues through GraphQL.
• Discover dependency edges from supported GitHub issue relationships where available; if dependency relationships are unavailable in the API, use the repo standard documented dependency syntax as a v1 fallback.
• If a valid child graph exists, seed the existing orchestration engine instead of creating a single parent task.
• Treat each child issue as one ABCA task using that child issue title/body/context.
• For v1, require all executable child issues to resolve to one active mapped repo.
• Release root child issues immediately; release dependent children only after all blockers complete successfully.
• Use existing orchestration behavior for branch stacking, failure propagation, skipped dependents, and terminal rollup.
• Post the parent rollup to the GitHub parent issue.

Acceptance criteria

• Applying the trigger label to a GitHub parent with a valid child graph creates child tasks and does not create a separate parent task.
• Child issues with no blockers start immediately.
• Blocked child issues start only after all blocking child tasks terminal-succeed.
• Failed or cancelled children skip their transitive dependents while independent siblings continue.
• The parent GitHub issue receives a rollup comment with succeeded, failed, skipped counts and child PR links where available.
• Cycles, unmapped child repos, or unsupported cross-repo graphs are rejected with a parent issue comment and no tasks created.
• Applying the trigger label to a GitHub issue without children keeps the current single-task behavior.

Tests

• GitHub processor tests cover parent-with-sub-issues, dependency edges, no-children fallback, cycles, unmapped children, and mixed repo rejection.
• Orchestration release tests cover GitHub channel metadata on child tasks.
• Rollup tests cover GitHub parent comments and non-GitHub behavior remaining unchanged.
• Docs explain supported GitHub hierarchy/dependency modeling.

Out of scope

• Auto-creating GitHub sub-issues from a plan.
• bgagent:decompose / bgagent:auto labels.
• Incrementally adding new sub-issues to an already-running orchestration.
• GitHub Projects automation.
• Cross-repo orchestration.

Empieza con el procesador de GitHub Issues y el motor de orquestación existente; inspecciona la ruta de descubrimiento de GraphQL y las pruebas del procesador, de release y de rollup mencionadas en el issue. Se considera terminado cuando los grafos hijos válidos crean tareas hijas conscientes de las dependencias, los grafos no válidos se rechazan con un comentario en el padre, los issues sin hijos conservan el comportamiento de una sola tarea y se documenta la jerarquía compatible.