fix(docker): drop COPY of gitignored data/ so staging image builds from a worktree

The staging-image rebuild (check_staging_image_fresh, ORCH-058) uses the task
git worktree as the docker build context. `data/` is gitignored (runtime SQLite
DB + backups) so it is absent in every worktree -> `COPY data/ ./data/` failed
the build (rc=1) -> deploy-staging rolled back to development (the loop ORCH-061
targets, surfaced one step later once the C9a/C9b waiver let the pipeline reach
the rebuild). The DB always arrives via the compose bind mount, so baking it in
was pointless (and leaked a stale host DB into the image).

Replace `COPY data/ ./data/` with `RUN mkdir -p /app/data` and add a static
regression guard asserting the Dockerfile never COPYs a gitignored path.

Refs: ORCH-061

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

Dockerfile

@@ -20,6 +20,15 @@ RUN groupadd -g 1000 app && useradd -u 1000 -g 1000 -m -d /home/slin -s /bin/bas
 COPY requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt
 COPY src/ ./src/
-COPY data/ ./data/
+# ORCH-061: do NOT `COPY data/ ./data/`. `data/` is gitignored (runtime SQLite DB
+# + backups), so it is ABSENT in every git worktree. The staging-image rebuild of
+# ORCH-058 (`check_staging_image_fresh` / hook `--build-staging`) uses the task
+# WORKTREE as the build context, where `data/` does not exist -> `COPY data/`
+# fails the build (rc=1) -> deploy-staging rolls back to development (the loop this
+# task fixes). It is also pointless: the DB always arrives via the compose bind
+# mount (`./data:/app/data` prod, `./data/staging:/app/data` staging), which
+# overrides anything baked in (and baking the host DB into the image leaks stale
+# state). Just ensure the mount target exists; sqlite creates the .db file.
+RUN mkdir -p /app/data
 ENV PYTHONPATH=/app
 CMD ["uvicorn", "src.main:app", "--host", "0.0.0.0", "--port", "8500"]