feat(github): support bgagent:decompose and bgagent:auto planning labels

## Component

CDK GitHub adapter, orchestration, agent workflows, CLI

## Describe the feature

GitHub Issues should support the same planning labels as Linear and the Jira parity work:

- `bgagent:decompose`: ABCA analyzes the GitHub issue, proposes a dependency-aware breakdown, posts the plan to GitHub, and waits for approval before creating/running child work.
- `bgagent:auto`: ABCA analyzes the issue, creates the breakdown, and starts the child work without an approval round.
- `bgagent:help`: ABCA posts a short comment explaining the supported GitHub trigger labels and creates no task.

## Use case

A large GitHub issue may need to be split before execution. Users should be able to keep that planning workflow inside GitHub Issues with the same scope/cost control available in Linear/Jira.

## Proposed solution

Extend the GitHub Issues label-trigger path to recognize label variants based on the configured base label:

- `` keeps current single-task behavior unless the issue already has an orchestratable child graph.
- `:decompose` creates a `coding/decompose-v1` planning task, posts the resulting plan as a GitHub issue comment, and records a pending plan awaiting approval.
- `:auto` creates the same plan and immediately seeds/runs the generated child graph.
- `:help` posts a GitHub help comment and exits.
- Add per-repo GitHub mapping options for decomposition enablement and max sub-issues, mirroring Linear/Jira parity.
- Preserve GitHub channel metadata on generated child tasks so comments, final status fanout, and later graph extension work.

## Acceptance criteria

- Adding `bgagent:help` to a GitHub issue posts a help comment and creates no task.
- Adding `bgagent:decompose` to an eligible GitHub issue creates a planning run and posts a proposed breakdown with cost/scope information and approval instructions.
- No implementation child tasks start until the plan is approved.
- Adding `bgagent:auto` creates a plan and starts the generated child graph without a human approval round.
- Per-repo caps reject over-large plans with a GitHub comment and no child tasks.
- Projects/repos without decomposition enabled reject `:decompose` / `:auto` with a clear GitHub comment.
- Existing plain-label GitHub behavior remains unchanged.

## Tests

- GitHub processor tests cover label variant parsing, help no-op, decompose planning task creation, auto path, disabled-repo rejection, and cap rejection.
- Orchestration tests cover pending-plan persistence and generated GitHub child task metadata.
- CLI tests cover GitHub mapping flags for decomposition enablement and max sub-issues.
- Docs update the GitHub Issues setup guide with label variants and cap configuration.

## Out of scope

- Running existing GitHub sub-issues/dependencies; tracked separately.
- Rich interactive plan revisions beyond the minimum approval path.
- Deterministic plan edit commands such as `drop 3` or `merge 1 2`.
- GitHub Projects automation.
- Cross-repo decomposition.

Start with the GitHub processor tests for label parsing and trigger handling, then trace the orchestration tests for pending-plan persistence and generated child-task metadata. Review the CLI tests for GitHub mapping flags and the GitHub Issues setup guide. Done means all listed acceptance paths pass, plain-label behavior is unchanged, and documentation covers label variants and caps.

Written by the indexing model from the issue text.