feat(github): extend existing orchestrations when new sub-issues are added

## Component

CDK GitHub adapter, orchestration

## Describe the feature

After a GitHub parent issue has already seeded an ABCA orchestration, re-applying the trigger label should let ABCA detect newly-added GitHub sub-issues or blocker relationships and extend the existing graph, matching Linear and Jira parity behavior.

## Use case

Teams often discover another task after an epic has started. A GitHub user should be able to add a sub-issue, re-apply the trigger label on the parent, and have ABCA add only the new work without rerunning completed children.

## Proposed solution

- On a GitHub parent label trigger, check whether an orchestration already exists for that parent issue.
- Re-read the current GitHub child graph and compare it with the stored orchestration graph.
- Add only genuinely new child issues and newly relevant blocker edges.
- Release new children immediately if their blockers have already succeeded; otherwise keep them pending until dependencies settle.
- If the orchestration is already terminal, allow a safe retry/extension that runs only the new child work and refreshes the parent rollup.
- If the graph has no new children, no-op or post a concise note consistently with Linear/Jira behavior.
- Preserve the same validation rules as initial GitHub orchestration: no cycles, no unsupported cross-repo graph, and no unmapped child repos.

## Acceptance criteria

- Re-applying the trigger label to a GitHub parent with newly-added sub-issues adds only the new child tasks.
- Existing terminal-success children are not rerun.
- New children whose dependencies already succeeded start immediately.
- New children blocked by unfinished or failed predecessors remain pending/skipped according to orchestration rules.
- Re-applying the trigger label with no new sub-issues is idempotent and does not duplicate tasks or rollup comments.
- Invalid graph changes are rejected with a GitHub parent comment and do not corrupt the existing orchestration.

## Tests

- GitHub processor tests cover existing orchestration detection, no-op retrigger, added-child retrigger, added dependency edge, cycle rejection, and unmapped child rejection.
- Orchestration store/release tests cover appending child rows without mutating completed child rows.
- Rollup tests cover refreshing the parent GitHub rollup after extension.
- Docs update the GitHub Issues setup guide with the add-sub-issue and re-apply-label workflow.

## Out of scope

- Automatically triggering when a GitHub sub-issue is created.
- Rerunning or replacing existing child tasks.
- Editing a generated decomposition plan.
- Cross-repo GitHub orchestration.
- A whole-epic cancel command.

Inizia con i test del processore GitHub e confronta il comportamento esistente delle estensioni Linear/Jira, poi leggi i test di orchestration store/release e rollup. Il lavoro è completato quando i nuovi trigger aggiungono solo nuovi elementi figli o archi, preservano le righe completate, gestiscono in sicurezza i grafi non validi, aggiornano il rollup del parent e la guida alla configurazione di GitHub Issues documenta il workflow.

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