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.

Beginne mit dem webhook processor, der bestehenden orchestration table, den dependency release- und reconciliation-Pfaden und untersuche anschließend den Forge proxy sowie den coding/pr-iteration-v1-Einstiegspunkt. Nutze die orchestration-, webhook-, store-, reconciliation- und integration tests, um das aktuelle Verhalten nachzuverfolgen. Erledigt bedeutet, dass READY-Eingänge einzelne Issues oder validierte Jira-Graphen ohne Duplikate ausführen, die Zuständigkeit des Anforderers beibehalten und Follow-ups nach aktiven Läufen einreihen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.