feat(modules): mount the modules directory as a volume (phase 2, PR 9)

Closes Phase 2. Modules live on a mount, never in the image — that is what
lets an operator add one to a pull-only deployment without building anything.

`./modules` is a bind mount rather than a named volume: placing a module
directory by hand is a supported install (MODULE_SYSTEM.md §2.5), and that has
to be doable from the host rather than through `docker cp`. Read-write, because
the admin panel's install/uninstall unpacks and removes directories there.

The directory is tracked via its README so it exists in the checkout with the
operator's own ownership — Docker recreates a missing bind-mount source as
root:root, which the container user could not then write. `.dockerignore`
excludes it so a module in the builder's working tree can never ship inside an
image.

Also corrects the route-manifest generator's list of filesystem-conditional
mounts, which never picked up `/modules` when PR 7 added it. Comment only; the
generator filters on an allowlist, so its behaviour was already right.

Verified against a real container, not just a parsed compose file: image
carries an empty node-owned /app/modules despite a module in the build context;
a module on the bind mount loads, mounts, replays and reaches `started`;
`/api/v1/public/modules` lists it; the chunk serves from the entry's directory
only (server source and module.json 404) with `no-cache`; the injected tag
follows core's bundle; and in Chrome the page renders on first paint inside
core's PublicLayout with its nav row interleaved into core's public nav, under
enforced `script-src 'self'` with zero CSP reports and no console errors.
Removing the directory by hand reconciles the row to `startup_failed`/`require`
and leaves core healthy with no injection.

933 server + 160 client tests pass, manifest unchanged at 230 routes, swagger
regenerates byte-identical.

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

docker-compose.yml

@@ -35,6 +35,10 @@ services:
       DB_HOST: db
       UPLOAD_DIR: /app/uploads
       LOG_DIR: /app/logs
+      # Where the loader scans for installed modules. Same path the code already
+      # 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
     depends_on:
       db:
         condition: service_healthy
@@ -47,6 +51,25 @@ services:
       # the image, so this mount only matters for custom brand images. Create
       # ./brand/ on the host and drop assets in; read-only in the container.
       - ./brand:/app/brand:ro
+      # Installed modules (docs/website/MODULE_SYSTEM.md). Modules live on a
+      # mount, NEVER in the image: that is what lets an operator add one to a
+      # 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`.
+      #
+      # Read-WRITE: the admin panel's install/uninstall unpacks and removes
+      # 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
+      # would recreate a missing bind-mount source as root:root and the container
+      # user could no longer write it. If the app runs as a uid that does not own
+      # ./modules, `chown 1000:1000 modules` on the host.
+      #
+      # Adding or removing a module takes a RESTART: the scan is synchronous at
+      # require time (MODULE_API.md §4.1), so nothing here is picked up live.
+      - ./modules:/app/modules
     # Only the PUBLIC API port (3000) is published. The internal server<->bot
     # port (INTERNAL_PORT, default 3001) is deliberately NOT listed here, so it
     # stays reachable only over the private compose network — Pangolin/the public