feat(orchestration): execute Slack-authored Jira epics and dependent sub-issues

## Parent and dependency

Part of #832. Blocked by #833.

## Summary

Turn a ready Slack-to-Jira intake into executable work. Support either a single Jira issue or an automatically inferred epic/parent with dependent sub-issues, while preserving the original Slack requester as the platform task owner.

## Implementation

- Extend the evaluator result with an optional validated work graph:
- parent specification;
- child summaries and descriptions;
- allowlisted issue types;
- dependency edges;
- acceptance criteria per child.
- Allow bgagent to choose single-issue or decomposed execution without human confirmation.
- Reject cycles, invalid references, unmapped projects, unsupported issue types, and cross-repository graphs.
- Extend the Forge proxy with narrowly allowlisted operations for:
- child issue creation;
- parent/sub-issue relationships;
- dependency issue links;
- execution-label updates.
- Materialize the Jira graph only after intake reaches `READY`.
- Extract reusable Jira orchestration seeding from the webhook processor.
- Seed orchestration directly with the Slack requester's platform user ID; do not attribute execution to the Forge app account.
- Reuse the existing orchestration table, dependency release, concurrency controls, stacked branches, reconciliation, and Jira progress behavior.
- Propagate a Slack intake identifier and thread metadata through orchestration parent, child, and task records.
- Transition the intake through `READY`, `RUNNING`, and terminal states using conditional writes.
- React with ⏳ when implementation begins.
- If a new mention arrives while work is running:
- ingest and update Jira immediately;
- persist the request as a queued follow-up;
- dispatch it through `coding/pr-iteration-v1` after the active run terminates.
- Prevent duplicate readiness evaluations, webhooks, or retries from launching duplicate tasks or child graphs.

## Acceptance criteria

- [ ] A ready single-issue intake starts one coding task automatically.
- [ ] A ready large request can create and execute a Jira parent with sub-issues.
- [ ] Dependencies form a validated DAG and control child release order.
- [ ] Independent children may run subject to existing concurrency limits.
- [ ] All executable children resolve to the parent repository.
- [ ] The original Slack requester owns all resulting platform tasks.
- [ ] Forge app attribution does not require a Jira-to-platform user mapping.
- [ ] Existing Jira label-triggered orchestration continues to work.
- [ ] Repeated events cannot duplicate children, orchestration rows, or coding tasks.
- [ ] Requirements arriving during execution are queued rather than injected into the live agent.
- [ ] Queued requirements run as a PR iteration after the active task settles.
- [ ] Orchestration, webhook, store, reconciliation, and integration tests pass.

## Out of scope

- General multi-repository orchestration.
- Human confirmation of the proposed decomposition.
- Live prompt mutation or cancellation of a running task.
- Final dual-surface rendering and scheduled abandonment.

Start with the webhook processor, existing orchestration table, dependency release and reconciliation paths, then inspect the Forge proxy and the coding/pr-iteration-v1 entry point. Use the orchestration, webhook, store, reconciliation, and integration tests to trace current behavior. Done means READY intakes execute single issues or validated Jira graphs without duplicates, preserve requester ownership, and queue follow-ups after active runs.

Written by the indexing model from the issue text.