4 modules: persistent data is a directory bind, never a named volume

hq ADR 0107 / issue 115. HAL's own postgres and lavinmq both used a
directory bind (./db-data, ./data) for exactly this data -- the mesh's
adoption of them, three weeks ago, switched to a named Docker volume
instead, and searxng/distribution followed the same pattern since.

A named volume survives ordinary container recreation, same as a
directory bind -- that was never the problem. The problem is everything
else: docker rm -fv, docker volume rm, and docker system prune --volumes
all target it (one flag away from the docker rm -f this migration already
uses routinely); it is invisible to every tool this migration has used all
night (ls, find, grep across /var/lib, /services); and nothing outside
Docker's own volume machinery can back it up or notice it growing.

mesh-store carries the sharpest version: every database migrated tonight,
including keycloak's, live inside it.

Data already copied and verified on novox before this merges:
- mesh-registry-data -> /var/lib/mesh-registry (11G, diff -rq clean)
- mesh-broker-data -> /var/lib/mesh-broker (37M, cp -a)
- mesh-broker-tls -> /var/lib/mesh-broker-tls (12K, cp -a)
- mesh-store-data -> /var/lib/mesh-store (1.7G) -- mesh-store stopped
  cleanly first, so the final copy is crash-consistent, not a live-file
  copy of a running postgres; diff -rq clean after.
- searxng/valkey: not yet assigned anywhere, manifest-only fix, nothing
  to copy.

Old named volumes left in place, not deleted, as the rollback path.

modules/distribution/module.json

@@ -42,6 +42,12 @@
       "path": "/var/lib/mesh/registry",
       "mode": "0700"
     },
+    {
+      "id": "registry-data",
+      "type": "directory",
+      "path": "/var/lib/mesh-registry",
+      "mode": "0700"
+    },
     {
       "id": "store",
       "type": "container",
@@ -51,7 +57,7 @@
         "5000:5000"
       ],
       "volumes": [
-        "mesh-registry-data:/var/lib/registry"
+        "/var/lib/mesh-registry:/var/lib/registry"
       ]
     }
   ]

modules/lavinmq/module.json

@@ -75,6 +75,18 @@
       "path": "/var/lib/lavinmq-module/grants",
       "mode": "0700"
     },
+    {
+      "id": "broker-data",
+      "type": "directory",
+      "path": "/var/lib/mesh-broker",
+      "mode": "0700"
+    },
+    {
+      "id": "broker-tls",
+      "type": "directory",
+      "path": "/var/lib/mesh-broker-tls",
+      "mode": "0700"
+    },
     {
       "id": "server",
       "type": "container",
@@ -86,8 +98,8 @@
         "127.0.0.1:15672:15672"
       ],
       "volumes": [
-        "mesh-broker-data:/var/lib/lavinmq",
-        "mesh-broker-tls:/tls:ro"
+        "/var/lib/mesh-broker:/var/lib/lavinmq",
+        "/var/lib/mesh-broker-tls:/tls:ro"
       ],
       "args": [
         "--amqps-port=5671",

modules/postgres/module.json

@@ -69,6 +69,12 @@
       "path": "/var/lib/postgres/grants",
       "mode": "0700"
     },
+    {
+      "id": "store-data",
+      "type": "directory",
+      "path": "/var/lib/mesh-store",
+      "mode": "0700"
+    },
     {
       "id": "server",
       "type": "container",
@@ -82,7 +88,7 @@
         "5432:5432"
       ],
       "volumes": [
-        "mesh-store-data:/var/lib/postgresql/data",
+        "/var/lib/mesh-store:/var/lib/postgresql/data",
         "/var/lib/postgres/superuser.secret:/run/secrets/superuser:ro"
       ]
     },

modules/searxng/module.json

@@ -29,6 +29,12 @@
       "path": "/var/lib/searxng-module",
       "mode": "0700"
     },
+    {
+      "id": "valkey-data",
+      "type": "directory",
+      "path": "/var/lib/searxng-module/valkey-data",
+      "mode": "0700"
+    },
     {
       "id": "server-env",
       "type": "file",
@@ -56,7 +62,7 @@
         "warning"
       ],
       "volumes": [
-        "searxng-valkey-data:/data"
+        "/var/lib/searxng-module/valkey-data:/data"
       ]
     },
     {