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>

.env.example

@@ -113,6 +113,20 @@ BOT_INTERNAL_KEY=change-me-to-a-long-random-string
 # knows nothing about any of them. A module may read its own env vars, and they
 # belong here because Compose passes this file to the container.
 #
+# MODULES declares the set this deployment runs, and the container arrives at it
+# on its own — no admin panel, no `tar -xf` on the host. One entry per module,
+# `<id>@<version>=<install manifest URL>`, whitespace- or comma-separated:
+#
+#   MODULES=uo@0.3.0=https://gitea.whitlocktech.com/RunicGateway/Module-uo/releases/download/v0.3.0/module-uo-0.3.0.json
+#
+# A module already unpacked at the declared version is a no-op that never touches
+# the network, so a restart with the internet down brings the site up exactly as
+# it was; only a missing or different version is fetched, verified against the
+# sha256 its manifest declares, and unpacked. A failure is logged and shown in
+# Admin → Modules, and the site starts anyway. The variable owns what is on the
+# volume, not what runs — a module disabled from the admin panel stays disabled.
+# Leave it unset to install from the admin panel instead.
+#
 # RunicGateway/Module-uo, for example, reads UOLINK_BASE_URL / UOLINK_WS_URL /
 # UOLINK_PROTOCOL as the defaults for its connection to a uo-link sidecar, and
 # TOWNCRIER_DURATION_SEC for its news leg. Its README documents them; they are