feat(orchestration): autonomous feedback loop (PR watcher → merge)

**Context:** ROADMAP.md → Agent quality → Autonomous feedback loop
**Related:** #22 (merge conflicts slice), pure decision function orchestrator draft, #425

---

## Component

API or orchestration

## Describe the feature

Extend orchestrator beyond **`PR_OPENED`** with a **PR watcher phase**. Auto-resume when:

- **CI fails** — inject failure logs
- **Merge conflicts** — rebase instructions (#22 related)
- **Reviewers request changes** — inline comments

Continue until **PR merged** or human **cancels**. Optionally **auto-merge** when CI passes and review approved.

**Outcome:** transforms ABCA from "open PR" to "merge PR".

## Use case

Today tasks often end at PR creation; humans must manually re-submit `pr_iteration` tasks for CI failures, review feedback, and merge conflicts. Teams want the agent to own the full PR lifecycle with guardrails.

## Proposed solution

1. New orchestrator phase(s): `AWAITING_PR_FEEDBACK` / `PR_WATCHING` with GitHub webhook + polling triggers.
2. Classify events: `check_suite.failure`, `pull_request_review.comment`, `merge_conflict`, `review_requested_changes`.
3. Resume agent with structured context injection; respect `max_turns`, `max_budget_usd`, Cedar HITL.
4. Optional policy-gated auto-merge (repo Blueprint flag).
5. Terminal states: `COMPLETED` (merged), `FAILED`, `CANCELLED`, or `AWAITING_HUMAN` when stuck.
6. **Prerequisite:** pure decision-function orchestrator refactor (separate draft) recommended for testability.

## Other information

- Distinct from **in-pipeline build/lint fix-up loop** (pre-PR, `pipeline.py` only).
- #22 covers merge-conflict handling in `pr_iteration` but not the full watcher loop.
- Design context: `docs/design/ORCHESTRATOR.md`, `docs/design/EVALUATION.md`.

- [x] This might be a breaking change

Inizia da ROADMAP.md e docs/design/ORCHESTRATOR.md, oltre a docs/design/EVALUATION.md, poi esamina l’orchestrator esistente e il flusso pr_iteration. Confronta le fasi proposte del watcher, gli eventi GitHub, i guardrails e gli stati terminali con #22, #425 e la bozza della funzione decisionale pura; pipeline.py è esplicitamente un ciclo pre-PR separato. Il lavoro è completo quando è implementato l’intero ciclo di vita del PR con la policy indicata e i confini dell’intervento umano stabiliti.

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