skaldsong: fix CD-wipes-state bug (env var names didn't match app)

The compose set SKALDSONG_DB_PATH + SKALDSONG_RUNS_DIR, but skaldsong's
app reads SKALDSONG_HOST_SQLITE_PATH + SKALDSONG_HOST_RUNS_ROOT (per
its Dockerfile ENV defaults). Our values were orthogonal — the app
fell back to Dockerfile defaults pointing at /app/data/... which is
NOT bind-mounted, so every --force-recreate wiped the SQLite DB +
runs/ tree along with the ephemeral container layer.

Surfaced by skaldsong-dev (althing thread 01KS4DPF6SXTBP4Q360JZVWPNT)
after the operator noticed stories vanishing on every deploy.

Confirmed on ana-docker: container had a 40KB skaldsong-ui.db sitting
in /app/data/, while /opt/docker/conf/skaldsong/db/ on the host was
empty. Rescued the live DB to the bind-mount target before recreate.

Fix: rename env vars to match what the app reads. Bind targets stay
at /app/state/{db,runs} (parent-dir mount for SQLite WAL+SHM).

stacks/skaldsong/compose.yaml

@@ -80,9 +80,15 @@ services:
 
       # Persistent state paths inside the container. The db/ parent
       # dir is the bind-mount target (not the file itself) so SQLite
-      # can write its WAL + SHM siblings.
-      SKALDSONG_DB_PATH: /app/state/db/skaldsong-ui.db
-      SKALDSONG_RUNS_DIR: /app/state/runs
+      # can write its WAL + SHM siblings. Names MUST match what the
+      # app actually reads (per skaldsong's Dockerfile ENV defaults):
+      # SKALDSONG_HOST_SQLITE_PATH + SKALDSONG_HOST_RUNS_ROOT. Earlier
+      # this block used SKALDSONG_DB_PATH / SKALDSONG_RUNS_DIR — those
+      # names are orthogonal to what the app reads, so the app fell
+      # back to Dockerfile defaults pointing at /app/data/... which
+      # is NOT bind-mounted → state wiped on every recreate.
+      SKALDSONG_HOST_SQLITE_PATH: /app/state/db/skaldsong-ui.db
+      SKALDSONG_HOST_RUNS_ROOT: /app/state/runs
     volumes:
       # db/ and runs/ are separate bind-mounts so runs/ can later move to
       # a bigger volume without touching DB state.