feat(modules): the declarative Docker path (phase 4, slice 3)

MODULES declares the module set a deployment runs, one entry per module as
`<id>@<version>=<install manifest URL>`, and the container arrives at it by
itself (MODULE_SYSTEM.md §2.7.2 decision 4). A module already unpacked at the
declared version is a no-op that makes NO network call, so a restart with the
network down comes up unchanged; anything else goes through install.js — same
allowlist, same sha256, same inspect-then-extract — and install() now takes an
`expect: {id, version}` so a URL resolving to another module or version is
refused while it is still only a manifest.

Resolution runs inside start(), between the seed and the require of app.js: the
seed is where the host allowlist setting comes from, and the require is what
scans the volume. That buys it the database, so a compose-installed module gets
the same provenance columns an admin install writes.

A failure is logged and carried, never fatal — an unreachable release host must
not take the site down. The declaration owns what is on the volume; the row owns
whether a module runs, so uninstalling a declared module returns its files at
the next start and leaves it disabled. The admin list gains that as a fourth
source (declared / declaredVersion / declaredError), because a declared module
that failed to resolve has no row, no directory and nothing mounted.

Deferring the app require moved core's schema ahead of the volume scan, and the
module schema-fragment replay was wired to core's schema — so every installed
module silently got no tables. Invisible to the suite (each one stubs the loader
or the pool) and to a smoke on a database that already had the tables; found by
booting against an empty one. ensureSchema() now takes `replayModules: false`
for the one caller that scans later, server.js replays them itself after the
require, and a bootOrder test pins the five steps in the only order they work in.

741 server tests (+18), 187 client (+5); manifest unchanged at 166 public + 2
internal, OpenAPI byte-identical.

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

docker-compose.yml

@@ -39,6 +39,24 @@ services:
       # defaults to (<repo>/modules, and the repo is /app in the image), set
       # explicitly because the bind mount below is what makes it meaningful.
       MODULES_DIR: /app/modules
+      # WHICH modules this deployment runs (MODULE_SYSTEM.md §2.7.2 decision 4).
+      # One entry per module, `<id>@<version>=<install manifest URL>`, whitespace-
+      # or comma-separated. The container resolves this set for itself at every
+      # start: a module already unpacked at the declared version is left alone
+      # without a single network call — so a restart with the internet down comes
+      # up unchanged — and only a missing or different version is fetched,
+      # verified against the sha256 its release manifest declares, and unpacked.
+      # A failure is logged and surfaced in Admin → Modules; it never stops the
+      # site from starting.
+      #
+      # Uncomment to declare a set here, in the file this host version-controls,
+      # or leave it out and set MODULES in .env (env_file above) — or leave it
+      # unset entirely and install from the admin panel. What it declares is what
+      # is ON the volume, never whether a module runs: a module disabled from the
+      # admin panel gets its files back and stays disabled.
+      #
+      # MODULES: >-
+      #   uo@0.3.0=https://gitea.whitlocktech.com/RunicGateway/Module-uo/releases/download/v0.3.0/module-uo-0.3.0.json
     depends_on:
       db:
         condition: service_healthy
@@ -56,10 +74,12 @@ services:
       # pull-only deployment without building anything. A bind mount rather than
       # a named volume because placing a module directory by hand is a supported
       # install — `tar -xf uo-1.0.0.tgz -C ./modules` then restart — and that has
-      # to be doable from the host, not through `docker cp`.
+      # to be doable from the host, not through `docker cp`. It is no longer the
+      # usual way in: declare MODULES above, or install from Admin → Modules.
       #
-      # Read-WRITE: the admin panel's install/uninstall unpacks and removes
-      # directories here from inside the container.
+      # Read-WRITE: MODULES resolution at start, and the admin panel's
+      # install/uninstall, both unpack and remove directories here from inside
+      # the container.
       #
       # `modules/` is tracked (it ships a README) so the directory exists in the
       # checkout with the operator's own ownership. Do not delete it — Docker