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.

Start with the GitHub processor tests and compare existing Linear/Jira extension behavior, then read the orchestration store/release and rollup tests. The work is done when retriggers append only new children or edges, preserve completed rows, handle invalid graphs safely, refresh the parent rollup, and the GitHub Issues setup guide documents the workflow.

Written by the indexing model from the issue text.