feat(ci): enforce runtime-validation image separation (#69)

## Summary

Implements issue #59 by enforcing a hard boundary between CI validation tooling and deployable runtime images.

This PR:

- Adds automated deployable-runtime boundary checks in CI.
- Verifies deployable backend/frontend artifacts are free of CI/development tooling.
- Documents runtime-vs-validation ownership and enforcement behavior.

## What Changed

### CI workflow enforcement

- Updated `.gitea/workflows/docker-build-main.yaml` to:
  - Checkout additional verification inputs (`Dockerfile.backend`, `Dockerfile.frontend`, scripts, backend/frontend directories).
  - Run `scripts/check-dockerfile-boundaries.sh`.
  - Build deployable runtime images (`Dockerfile.backend`, `Dockerfile.frontend --target production`).
  - Run `scripts/verify-deployable-image-purity.sh` against both images before publishing CICD image.

- Updated `.gitea/workflows/cicd-checks.yaml` to add:
  - `dockerfile-boundary-check` job.
  - Boundary validation execution inside the CICD validation image.

### New enforcement scripts

- Added `scripts/check-dockerfile-boundaries.sh`:
  - Ensures deployable Dockerfiles do **not** reference CICD image paths (`cicd-base`, `CICD_BASE_IMAGE`, `Dockerfile.cicd*`, etc.).
  - Ensures deployable Dockerfiles do **not** include disallowed CI-only tooling tokens.
  - Enforces runtime base expectations:
    - Backend: `python:3.14-slim`
    - Frontend production target: `nginx:alpine`

- Added `scripts/verify-deployable-image-purity.sh`:
  - Baseline binary checks for disallowed tooling.
  - Backend-specific deep checks:
    - Python module import probes for disallowed CI/dev modules.
    - `pip show` package metadata checks for disallowed CI/dev packages.
  - Frontend-specific deep checks:
    - OS package metadata checks (`apk`/`dpkg` when available) for disallowed runtime leaks.
    - Directory-based checks for development package trees (`node_modules`, `.venv`, `site-packages`, `dist-packages` in sensitive paths).

## Documentation updates

- Updated `docs/DEVELOPMENT.md`:
  - Clarifies runtime-vs-validation enforcement and where checks run.
  - Notes purity checks include binaries and metadata artifacts.

- Updated `docs/CICD_MULTI_STAGE_BUILD.md`:
  - Adds explicit “Runtime Boundary Enforcement” section.
  - Documents metadata-level purity probes.

- Updated `docs/DEPLOYABLE_RUNTIME_CONTRACT.md`:
  - Replaces future-only language with current enforcement hooks.
  - Documents binary + metadata-level purity enforcement.

## Acceptance Criteria Mapping

1. **Deployable backend/frontend image paths do not require CI-only tool installation**
   - Enforced by:
     - `scripts/check-dockerfile-boundaries.sh`
     - `scripts/verify-deployable-image-purity.sh`
     - `docker-build-main.yaml` pre-publish gates

2. **Checks and tests execute in dedicated validation environment(s)**
   - Reinforced by:
     - `cicd-checks.yaml` boundary-check job running in CICD validation image
     - Existing check/test workflow usage of CICD image

3. **Workflow docs identify runtime vs validation concerns**
   - Addressed via updates to:
     - `docs/DEVELOPMENT.md`
     - `docs/CICD_MULTI_STAGE_BUILD.md`
     - `docs/DEPLOYABLE_RUNTIME_CONTRACT.md`

## Scope / Non-Goals

- Included:
  - Structural separation enforcement
  - Workflow-level guardrails
  - Documentation clarity and traceability

- Not included:
  - Full staging deployment wiring
  - Security policy redesign

## Notes for Reviewers

- Main enforcement path is in `docker-build-main.yaml` before CICD image publish.
- New scripts are intentionally fail-fast and policy-oriented.
- Existing deployable Dockerfiles currently satisfy the new gates.

Co-authored-by: copilotcoder <copilotcoder@darkhelm.org>
Reviewed-on: #69

docs/DEVELOPMENT.md

@@ -34,9 +34,34 @@ When changing deployment behavior or image composition, treat
 
 Scope boundary:
 
-- This repository separates contract definition from enforcement mechanics.
-- CI workflow rewiring and test execution redesign are out of scope for PP-58
-  and belong to follow-up work under epic #66.
+- Contract definition lives in `DEPLOYABLE_RUNTIME_CONTRACT.md`.
+- CI enforcement now includes Dockerfile boundary checks and deployable image
+  purity checks in `.gitea/workflows/docker-build-main.yaml`.
+- Broader workflow redesign and deployment wiring remain out of scope for this
+  repository's runtime contract document and belong to follow-up work under
+  epic #66.
+
+## Runtime vs Validation Enforcement
+
+Deployable runtime artifacts and validation environments are intentionally
+separated.
+
+- Validation tools (lint/typecheck/test/browser tooling) belong to CICD image
+  paths (`Dockerfile.cicd-base`, `Dockerfile.cicd`) and CI validation
+  workflows.
+- Deployable runtime paths (`Dockerfile.backend`, `Dockerfile.frontend`
+  production target) must remain independent of CI-only tooling layers.
+
+Automated checks:
+
+- `scripts/check-dockerfile-boundaries.sh` validates deployable Dockerfiles do
+  not depend on CICD images or install disallowed CI-only tools.
+- `scripts/verify-deployable-image-purity.sh` inspects built deployable images
+  and fails if CI/development binaries or package metadata artifacts are
+  present.
+
+These checks run in `.gitea/workflows/docker-build-main.yaml` before publishing
+the complete CICD image.
 
 ## Quick Start