fix(packaging): the hub unit can start, and nothing carries the migration path

`ExecStartPre` ran `alembic -c /opt/meshbay-hub/migrations/alembic.ini upgrade
head`. The build does stage that file, so the path existed and the contents
were wrong: `alembic.ini` resolves `script_location` with `%(here)s`, so the
copy pointed at `/opt/meshbay-hub/migrations/src/meshbay_hub/db/migrations` —
which nothing installs, because the migrations ship inside `meshbay_hub`, in
the shared venv.

`ExecStartPre` failing stops the unit. A hub installed from the RPM or the DEB
could not start at all, and nothing noticed because the one live deployment
was assembled by hand — the same shape as the node unit that carried `User=`
into the user unit directory.

The same `%(here)s` trap was already found once on the server, where a stray
`alembic.ini` resolved to a month-old snapshot of the tree. Twice is a trap
rather than an accident, so the fix is that the path is no longer written down
anywhere: `meshbay-hub migrate` asks the installed package where its own
migrations are, which is correct for the RPM, the DEB, a venv and a checkout.
The build stages no `alembic.ini`; the repo keeps its own for `alembic
revision` and for deploy scripts that already work.

`env.py` now prefers a URL the caller resolved over re-reading the environment
itself, so `migrate --config` connects with exactly the string the server
will — one resolution, not two that agree until they do not.

Six tests, three of which fail against the unit as it was. They read the
directives rather than the file, because searching the whole thing finds the
comment explaining a directive and calls that the directive.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T4YmK41VsEURWFdop4EEeT

1 files changed, 15 insertions, 1 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index 3027a21..10792aa 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -122,7 +122,7 @@ that produced it.
 | Looking for | Read |
 |---|---|
 | What a label means (`C1`, `H3`, `NS6`, `T3`, `C5b`, `W2`, `E9`, `F1`, `AV4`, …) | `docs/MESHBAY_DESIGN.md` §13 |
-| What one member can cost the others (`AV1`–`AV18`) | §13.5b — the newest category, and the one the first three reviews had no question for |
+| What one member can cost the others (`AV1`–`AV19`) | §13.5b — the newest category, and the one the first three reviews had no question for |
 | Trust model, and what the project may and may not claim | §2 |
 | Identity, devices, admission, recovery, the keypair bundle | §3 |
 | Cryptography, key hierarchy, the group and chat envelopes | §4 |
@@ -148,6 +148,20 @@ These are about working on the tree rather than about the design:
   interface, for the web and the app alike; `packages/meshbay-client/scripts/
   sync-ui.js` copies it (`npm run sync-ui`) and CI fails if the copy drifts —
   **never edit `packages/meshbay-client/ui/` by hand**
+- **`%(here)s` in `alembic.ini` makes a copy of it correct only where it was
+  copied from.** The packaged unit ran `alembic -c
+  /opt/meshbay-hub/migrations/alembic.ini`, a file the build did stage — so the
+  path existed and the *contents* were wrong: `script_location` resolved to
+  `…/migrations/src/meshbay_hub/db/migrations`, which nothing installs, because
+  the migrations ship inside `meshbay_hub` in the shared venv. `ExecStartPre`
+  failing stops the unit, so **a hub installed from the RPM or the DEB could
+  not start at all**, and nothing noticed because the one live deployment was
+  assembled by hand. The same trap had already been found on the server, where
+  a stray `alembic.ini` pointed at a month-old snapshot. Twice is a trap: the
+  path is not written down anywhere now — `meshbay-hub migrate` asks the
+  installed package where its own migrations are, which is right for a
+  package, a venv and a checkout alike
+
 - **`node --check` reports success on a module-syntax error, and a green one
   cost a full suite run.** An unclosed `.map(` inside a tagged template came
   back clean four times in a row. `test_spa_syntax.py` says this in its own