Démarrage de la pile par un simple docker compose up

La pile de test de la branche ne démarrait pas : « Connexion à la base
impossible ». Trois causes cumulées, toutes corrigées.

1. PTA_DB_PORT et DB_PORT étaient passés à 9306. Ces variables désignent le
   port joint À L'INTÉRIEUR du réseau Docker, où MariaDB écoute sur 3306, et
   non un port publié sur l'hôte : la connexion était refusée. Elles reviennent
   à 3306, et le port hôte 9306 est désormais réellement publié par le service
   db (sur la boucle locale), pour un client SQL externe.

2. Le service db-migrate manquait sur la branche. Le schéma d'initialisation ne
   contient aucune des tables et vues d'accès V7.8 : sur un volume neuf,
   l'application refusait de démarrer. db-migrate applique maintenant tous les
   database/migration_*.sql, dont celle du tableau de bord V7.9 — plus aucune
   étape SQL manuelle.

3. Le défaut de PTA_DB_PASS (change_me) différait de celui de MARIADB_PASSWORD
   (pta). Sans fichier .env — et ce répertoire n'en a pas, il est ignoré par
   git — l'authentification échouait. Les deux défauts sont alignés.

Le bandeau du tableau de bord ne prétend plus que « tous les lieux ont des
horaires attendus » quand aucun lieu n'est enregistré.

Vérifié : volume détruit puis « docker compose up -d --build » seul suffit à
obtenir les onze pages en 200, l'atterrissage sur le tableau de bord et les deux
migrations appliquées ; un second up les ignore ; la base répond sur
127.0.0.1:9306 ; la pile principale sur 8080 est restée intacte.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README_V7_9.md

@@ -70,22 +70,25 @@ L'endpoint `api/dashboard_summary.php` est gardé par `requireService()` : 403 p
 
 ## Migration
 
-```sql
-SOURCE database/migration_v7_9_tableau_de_bord.sql;
+Aucun geste manuel : `database/migration_v7_9_tableau_de_bord.sql` est appliqué au démarrage par le
+service `db-migrate`, qui joue tous les `database/migration_*.sql` dans l'ordre. Un simple
+
+```bash
+docker compose up -d --build
 ```
 
-Elle insère une seule ligne dans `acces_role_page`. **Elle doit être jouée en même temps que le
-déploiement du code**, dans un sens comme dans l'autre :
+suffit, sur base neuve comme sur base existante. La migration insère une seule ligne dans
+`acces_role_page` et est idempotente (`ON DUPLICATE KEY UPDATE`).
 
-- code déployé, migration non jouée → l'onglet n'apparaît pas, le Service Enfance atterrit comme
-  avant sur l'écran de saisie, et `dashboard.php` renvoie vers l'accueil. L'application reste
-  entièrement fonctionnelle, simplement sans tableau de bord ;
-- migration jouée, code non déployé → l'onglet apparaît et pointe vers un fichier inexistant.
+Si la migration n'était pas jouée, l'onglet n'apparaîtrait pas, le Service Enfance atterrirait comme
+avant sur l'écran de saisie et `dashboard.php` renverrait vers l'accueil : l'application resterait
+entièrement fonctionnelle, simplement sans tableau de bord.
 
 Retour arrière :
 
 ```sql
 DELETE FROM acces_role_page WHERE role = 'SERVICE_ENFANCE' AND page = 'dashboard';
+DELETE FROM schema_migration WHERE fichier = 'migration_v7_9_tableau_de_bord.sql';
 ```
 
 ## Fichiers
@@ -102,6 +105,8 @@ DELETE FROM acces_role_page WHERE role = 'SERVICE_ENFANCE' AND page = 'dashboard
 
 | Modifié | Raison |
 | --- | --- |
+| `docker-compose.yml` | service `db-migrate`, port interne de la base rétabli à 3306, défaut de mot de passe aligné entre `db` et `php` |
+| `docker/db/apply-migrations.sh` | application automatique et idempotente des migrations |
 | `app/Core/Access.php` | `homeUrl()` vise le tableau de bord, avec repli si la migration manque |
 | `app/Controllers/PageController.php` | méthode `dashboard()` et sous-titre propre à chaque page |
 | `app/Views/layouts/header.php` | navigation regroupée, sous-titre contextuel |