epic(ux): interactive task UX Phase 2

Personne n'a encore pris cette issue.

**Context:** ROADMAP.md → Interactive task UX (section)
**Related:** #53 (hydration follow-up, not ask), `docs/design/INTERACTIVE_AGENTS.md`

---

## Component

API or orchestration

## Describe the feature

Epic for **Phase 2 interactive UX** beyond shipped `bgagent status`, `watch`, and `nudge`: manager-style progress, mid-run `bgagent ask`, and optional LLM-synthesized status.

## Use case

Deterministic status snapshots answer ops questions but not "what did you decide and what's next?" Operators want consistent, auditable progress across CLI and notification channels.

## Proposed solution

Child issues:

| Draft | Capability |
|-------|------------|
| [smart-progress-updates.md](./smart-progress-updates.md) | Manager-style progress events |
| [bgagent-ask-phase2.md](./bgagent-ask-phase2.md) | `bgagent ask` + REST API |
| [llm-synthesized-status-summary.md](./llm-synthesized-status-summary.md) | Optional LLM status mode |

Design authority: `docs/design/INTERACTIVE_AGENTS.md` (Phase 2 section).

## Other information

- Fanout already forward-compat subscribes to `status_response` (not yet emitted).
- Distinct from **LLM-assisted trace analysis** (post-mortem).

- [ ] This might be a breaking change

Commencez par la section Interactive task UX de ROADMAP.md et la section Phase 2 de docs/design/INTERACTIVE_AGENTS.md, puis examinez smart-progress-updates.md, bgagent-ask-phase2.md et llm-synthesized-status-summary.md. Il s’agit davantage d’un epic que d’une modification autonome ; le travail est considéré comme terminé lorsque les capacités enfants sélectionnées sont implémentées et validées conformément au design.

Rédigé par le modèle d'indexation à partir du texte de l'issue.