Document today's restructures, and give data/ a README that ships with it

Deployment/README-Deployment.md

@@ -135,6 +135,28 @@ and a third node would work with no template change at all.
 |--------|------|-------------|
 | `conf_upgrade.sh` | Merge template into conf — structure forward, values preserved | Automatically, after every `git pull` |
 | `conf_populate.sh` | Detect settings from running services into the host conf | Manually — onboarding, or after a key rotation |
+| `migrate_data_layout.sh` | Move everything persisted into the rooted `data/` tree | Once per host, manually. Idempotent. |
+
+### 📦  Data layout migration — `migrate_data_layout.sh`
+
+`conf_upgrade.sh` adds keys the template has and the installation does not; it never rewrites a
+value you already have. That is exactly what you want from it, and exactly why it cannot perform
+a layout migration — the paths being moved are *existing* keys, so their values would keep
+pointing at the old layout forever while the new directory variables sat beside them unused.
+
+So this rewrites those values and moves the files to match. Both halves or neither.
+
+```bash
+Deployment/migrate_data_layout.sh --dry-run    # always first
+Deployment/migrate_data_layout.sh
+```
+
+It refuses to run while a job from *this* installation is active — scoped to the installation's
+own path, because `pgrep` is system-wide and a box running both a production checkout and a
+development clone will otherwise always look busy. `--force` overrides.
+
+Each host runs it itself: `data/` is gitignored, so a restructure travels as code and conf while
+the files stay where they are. See `data/README.md` for the resulting layout.
 
 | Template | Role |
 |----------|------|