Pipeliner Client

### Problème
Actuellement, les développeurs et les product owners doivent manuellement décider si un ticket Redmine doit être découpé en sous-tâches et spécifier ces sous-tâches. Ce processus est chronophage et sujet à des oublis, surtout pour les tickets complexes (ex. : applications mobiles).

### Contexte
Dans le cadre du projet **pipeliner**, nous souhaitons automatiser cette décision en créant un **agent Scrum Master / Dev Spec** invocable par d'autres agents. Cet agent analysera les tickets soumis (`status = "Submitted"`) pour :
- Déterminer si un découpage est nécessaire.
- Proposer une décomposition détaillée en sous-tâches si applicable.
- Faire avancer le ticket dans le pipeline (`Submitted → Spec → In development`).
- Mettre à jour le tableau de bord **Pipeliner** et l'**Aggregator** pour refléter ces changements.

> **⚠️ MISE À JOUR (gouvernance des statuts, 2026-06-11)** — le statut `ready_for_dev` initialement demandé est **abandonné** : c'est une *frontière* entre `Spec` et `In development`, pas une étape où le travail se trouve. On réutilise le workflow canonique existant (8 statuts, ids 7–14) — voir `docs/superpowers/specs/2026-06-11-redmine-status-governance.md` §5.2. **Aucun nouveau statut.** Les transitions sont pilotées par `allowed_statuses` (jamais d'ids ni de noms codés en dur).

### Comportement proposé
1. **Déclenchement** : l'agent reçoit un ticket Redmine avec `status = "Submitted"`.
2. **Passage en Spec** : le ticket passe en `status = "Spec"` (via la transition autorisée) pour indiquer qu'il est en cours de spécification.
3. **Analyse** : l'agent applique les règles de découpage (ne pas découper bugfix / petites améliorations ; découper applications mobiles / tâches complexes).
4. **Proposition** : si un découpage est nécessaire, l'agent génère une proposition de sous-tâches (JSON) ajoutée en commentaire Redmine, et crée les sous-tâches (issues enfants, `parent_issue_id`).
5. **Spec terminée** : la complétude de la spec est signalée **sans nouveau statut** — `spec_ref` renseigné + `done_ratio` à 100 % sur le statut `Spec`. La colonne « Prêt pour le développement » du board = la colonne **Spec** à ce moment-là.
6. **Démarrage du dev** : au moment où le développement est pris en charge, l'agent (ou le Senior Dev) fait la transition `Spec → In development`.

### Contraintes
- **Aucun nouveau statut Redmine** : on n'utilise que les statuts canoniques `Submitted` / `Spec` / `In development`.
- Les sous-tâches conservent la **langue originale** du ticket.
- Les mutations respectent les règles de verrouillage : un ticket est éditable uniquement en `Submitted` / `Spec` ; une fois en `In development` il est verrouillé (`TicketLocked` → 403).
- Toute transition de statut est décidée à partir de `allowed_statuses` retourné par Redmine.

## Acceptance criteria
- [ ] **Passage en Spec** : l'agent passe systématiquement le ticket de `Submitted` à `Spec` (transition issue de `allowed_statuses`) avant l'analyse.
- [ ] **Règles de découpage** : l'agent ne découpe pas `bugfix` / `content_update` / petite amélioration, mais découpe applications mobiles / tâches complexes.
- [ ] **Proposition de sous-tâches** : si `should_split = true`, un JSON structuré (titres, descriptions, critères d'acceptation, dépendances, estimation répartie) est ajouté en commentaire Redmine et les sous-tâches sont créées comme issues enfants.
- [ ] **Spec terminée sans nouveau statut** : la complétude est signalée par `spec_ref` renseigné + `done_ratio = 100` sur le statut `Spec` (PAS de statut `ready_for_dev`).
- [ ] **Démarrage du dev** : la transition `Spec → In development` est effectuée au moment de la prise en charge du développement (automatique si `should_split = false`, après validation PO si `should_split = true`).
- [ ] **Tableau de bord Pipeliner** : les tickets en `Spec` apparaissent dans la colonne **Spec** (la notion « prêt pour le développement » = Spec complète) ; ceux en `In development` dans la colonne **In development**.
- [ ] **Aggregator** : aucune modification du mapping des statuts nécessaire (workflow inchangé) ; les comptes `by_stage` restent corrects.
- [ ] **Pilotage par allowed_statuses** : l'agent ne code en dur aucun id ni nom de statut ; il lit les transitions légales sur l'issue.
- [ ] **Sécurité / verrouillage** : toute tentative de mutation d'un ticket au-delà de `Spec` renvoie `TicketLocked` (403).
- [ ] **Tests** : suite backend (intégration incluse) verte deux fois sur une même base ; mypy, ruff, et frontend (tsc, vitest, eslint) verts.
- [ ] **Déploiement** : vérification manuelle sur la production via `/browse` (tickets correctement positionnés dans Pipeliner et Redmine).