feat: media library, production DB tier, and CI gaps

[ssavutu]

Media library (API + page), the production database tier, and two CI gaps closed.

Merge before the first self-hosted-runner deploy. deploy.yml checks out
deployment code from the protected default branch, so until this lands, main
carries neither the media library nor the hardened deployment_preflight in
common.sh.

(An earlier version of this note claimed a deploy from main would overwrite the
Nginx site and kill media serving. That is not the case: the deploy scripts
only rewrite active-upstreams.conf — four set directives naming the active
slot's ports — and never touch sites-enabled. The site config carrying
/wp-content/ is installed manually during bootstrap and is already live on
Delta. Merging matters for the code, not to protect media serving.)

Media library

GET /v1/media, /v1/media/{id}, and /v1/media/gallery previously returned 501
via a misnamed handlers.Users placeholder, and the Media page's Upload and Delete
buttons were inert.

• New media table via EnsureMediaTable, following the existing runtime-schema
  pattern. path (wp-content-relative) is the row's stable identity; url is
  rendered through MEDIA_BASE_URL per response rather than stored, so it can't go
  stale if the media host changes.
• List (paginated, server-side search, MIME-family filter, sort), gallery shape for
  pickers, get, PATCH for alt text/caption, and DELETE.
• POST /v1/media/index walks MEDIA_ROOT and adds anything missing — this is how
  the migrated corpus enters the library. It skips WordPress's generated -WxH
  derivatives, which would otherwise bury the library in near-duplicates, and
  re-running preserves alt text already curated in the CMS.
• POST /v1/media (upload) is ported from patch/media-url-canonicalization and
  now also records the library row.
• DELETE refuses with 409 if any article still references the asset, so a
  delete here can't blank out a published page's image.
• Frontend: multi-file upload, debounced server-side search, paging, a detail panel
  for alt text/caption, and a reindex action. Upload/delete/reindex are admin-gated.
• TrixEditor posted to a bare /v1/media with no credentials. That was harmless
  while the endpoint returned 501 to everyone, but 401s now that upload is
  auth-gated and the API commonly runs on a different origin — it now uses
  apiBaseUrl() with credentials, matching useApiFetch.

Database tier

Config for the hosts that were actually provisioned: 4 vCPU / 4 GB unprivileged
LXC containers, not the 8–16 GB VMs originally requested.

• innodb_buffer_pool_size 5G → 1G. The entire dataset is ~92 MB, and a 5G pool
  on a 4 GB host prevents startup outright.
• innodb_log_file_size 512M → 256M.
• Dropped innodb_buffer_pool_instances, removed in MariaDB 10.6. Verified 11.x
  accepts and ignores it silently rather than refusing to start, so this is a
  cleanup, not a fix.
• bind-address pinned to the primary's NIC — Ubuntu's stock 50-server.cnf binds
  127.0.0.1, which leaves the primary unreachable from MaxScale.
• query_classifier_cache_size set explicitly. MaxScale defaults to ~15% of system
  memory, but inside an LXC whose cgroup limit reads max it sees the Proxmox
  host's RAM: it sized the cache at 9.38 GiB on a 4 GB container. Now 64M.

Note the deployed hosts run these natively via apt, not through the compose files
(Docker in unprivileged LXC needs Proxmox-side nesting), and MariaDB is 11.8 LTS
rather than the 11.7 pinned here — deb.mariadb.org carries only LTS lines and 11.7
is an EOL short-term release.

CI

• deploy_scripts_test.sh now runs in CI. It existed but nothing invoked it, so
  the least reversible code in the repo — slot selection, the transactional Nginx
  switch and its restore-on-failure paths, the preflight checks — had a suite that
  never ran on a PR. It stubs docker/curl/nginx on PATH, so it needs no
  daemon or privileges.
• New rollback.yml. rollback.sh was only invocable by SSH-ing into Delta from
  inside the VPN during an incident. Now a manual workflow on the same runner and
  trust boundary as deploy.yml, sharing the delta-production-deploy concurrency
  group so a rollback can never interleave with a deployment. No packages
  permission, since switching slots pulls no images.

Testing

• Server: go build, go vet, go test ./... all clean.
• Frontend: tsc -b and eslint clean, production build succeeds.
• Media storage guarantees covered without a database (no-clobber naming, filename
  sanitising, path containment), plus CMS_TEST_DSN-gated integration tests for the
  DB and HTTP layers, following the existing pattern. Run against a real MariaDB
  11.8, not left skipping: upload → list → patch → delete, the 409-in-use path,
  reindex idempotency, and derivative-skipping all verified. The two integration
  suites serialise on a MySQL advisory lock because they share the media table and
  go test ./... runs packages in parallel.
• Swagger docs regenerated.

After merge

1. Run the media index once, after the media rsync — the corpus is on disk but
   invisible to the CMS until then: Media → Reindex, or
   POST /v1/media/index. It's a full walk of the tree, so allow time on the real
   corpus; idempotent and safe to re-run.
2. GET /v1/articles returning 401 without a session is expected on this build; the
   read un-gating is on the separate patch/media-url-canonicalization branch.

Note on scope

The media commit also carries in-progress polls/comments work that was already
modified in the working tree. Those changes share files with the media work
(routes.go, main.go, types.go, api_responses.go) and couldn't be split
without interactive hunk staging.

Unrelated, but flagged by the push: server/internal/database/init_schema.sql is
50.06 MB, past GitHub's recommended maximum and heading for the 100 MB hard
limit that blocks pushes. It's a generated seed, so it probably wants git-ignoring
or LFS.