feat(orchestration): admission backlog observability

**Context:** ROADMAP.md → Admission backlog observability
**Related:** admission-queue-deferred-pickup draft, #331 (closed)

---

## Component

API or orchestration

## Describe the feature

**CloudWatch metric and alarm** when `SUBMITTED` task depth exceeds an operator threshold—surfacing capacity and admission health before users see failures.

## Use case

Operators cannot distinguish healthy queueing from stuck hydration or admission starvation. Proactive metrics reduce incident time.

## Proposed solution

1. Scheduled or stream-derived gauge: count tasks in `SUBMITTED` per user/fleet.
2. Dashboard widget + alarm with configurable threshold.
3. Optional dimension: time-in-SUBMITTED p95.
4. Document runbook: scale concurrency, investigate hydrator, enable admission queue when shipped.

## Other information

- Pair with **admission queue** draft.
- Design context: `docs/design/OBSERVABILITY.md`, `docs/design/ORCHESTRATOR.md`.

- [ ] This might be a breaking change

Iniziare da ROADMAP.md e dal contesto di progettazione in docs/design/OBSERVABILITY.md e docs/design/ORCHESTRATOR.md, quindi esaminare la bozza admission-queue-deferred-pickup e l’issue #331. Definire l’ambito di implementazione per SUBMITTED-depth e le metriche opzionali time-in-SUBMITTED, la dashboard e l’allarme configurabile, nonché il runbook dell’operatore; il completamento deve coprire gli elementi concordati di osservabilità e documentazione.

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