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.

Inizia con il processore di GitHub Issues e il motore di orchestrazione esistente; esamina il percorso di discovery di GraphQL e i test del processore, di release e di rollup indicati nell’issue. Il lavoro è completo quando i grafi figli validi creano task figli consapevoli delle dipendenze, i grafi non validi vengono rifiutati con un commento sul parent, le issue senza figli mantengono il comportamento con un singolo task e la gerarchia supportata è documentata.

Scritto dal modello di indicizzazione a partire dal testo della issue.