chore(ci): tidy CI/dev infra — drop local-ci, lift migration rule, scope by galaxy.stack label

Five connected cleanups across the dev/CI infrastructure:

1. Drop tools/local-ci/. The standalone Gitea + act_runner stack was
   the legacy "offline workflow validator"; the per-stage CI gate now
   runs on gitea.lan and the directory was only retained as a
   fallback. Removing it leaves no operational dependency: backend,
   gateway, and game code have no references; documentation that
   pointed at it (CLAUDE.md, docs/ARCHITECTURE.md, ui/docs/testing.md,
   tools/dev-deploy/README.md, tools/local-dev/README.md) is updated
   in this same change. Historical "Verified on local-ci run N"
   markers in ui/PLAN.md are preserved unchanged.

2. Lift the pre-production single-migration rule. The rule forced
   every schema delta into 00001_init.sql and required a manual
   make clean-data wipe on every backward-incompatible change in
   tools/dev-deploy/. Future schema deltas now land as additive
   sequence-numbered files (00002_*.sql, …) that goose applies
   automatically on backend startup; 00001_init.sql becomes an
   immutable baseline. Authoring conventions live in
   backend/internal/postgres/migrations/README.md. The chain may be
   squashed back into a fresh 00001 as a deliberate one-time
   operation before the first production deployment.

3. Document the deployment cadence. The dev environment is
   single-tenant: pushes to feature/* run the test workflows
   (go-unit, ui-test, integration) only; dev-deploy.yaml fires on
   push to development. A workflow_dispatch override on
   dev-deploy.yaml lets a developer preview a feature branch on the
   shared dev environment before merge; the next merge into
   development overwrites the manual deploy idempotently.

4. Scope compose-managed resources by an explicit
   galaxy.stack=<local-dev|dev-deploy> label. Both compose files
   stamp the label on every service, network, and named volume.
   Makefiles in tools/local-dev/ and tools/dev-deploy/ filter their
   engine-cleanup operations by (stack-label AND engine OCI title)
   so they never touch unrelated workloads on the same daemon.
   dev-deploy.yaml gains a pre-`compose up` step that reaps stale
   exited/dead containers under the dev-deploy stack label.

5. Backend now stamps the same galaxy.stack=<value> label on every
   engine container it spawns, sourced from a new BACKEND_STACK_LABEL
   env var (empty → label not applied; legacy-safe). Both compose
   files set it to their stack name (local-dev / dev-deploy). The
   contract is recorded in docs/ARCHITECTURE.md under
   "Container labels". A package-level test in
   backend/internal/runtime exercises both the label-present and
   label-absent paths.

No tests intentionally regressed: go test ./backend/internal/{config,
runtime,dockerclient} is green, both compose files validate cleanly,
and the backend, gateway, and game modules all build.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -46,7 +46,7 @@ Branches:
   it auto-deploys to the dev environment via `dev-deploy.yaml`
   (reachable at `https://www.galaxy.lan` / `https://api.galaxy.lan`).
 - `feature/*` — short-lived branches off `development`. Merged back
-  via PR; only then do they reach the dev environment.
+  via PR; only then do they reach the dev environment automatically.
 
 Workflows in `.gitea/workflows/`:
 
@@ -55,10 +55,24 @@ Workflows in `.gitea/workflows/`:
 | `go-unit.yaml` | push + PR matching Go paths | Fast Go unit tests. |
 | `ui-test.yaml` | push + PR matching `ui/**` | Vitest + Playwright. |
 | `integration.yaml` | PR to `development`/`main`; push to `development` | testcontainers integration suite. |
-| `dev-deploy.yaml` | push to `development` | Build images + (re)deploy to `tools/dev-deploy/`. |
+| `dev-deploy.yaml` | push to `development`; `workflow_dispatch` on any ref | Build images + (re)deploy to `tools/dev-deploy/`. |
 | `prod-build.yaml` | push to `main` | Build prod images and `docker save` into artifacts. |
 | `deploy-prod.yaml` | `workflow_dispatch` | Manual rollout (placeholder until prod host exists). |
 
+### Deployment cadence
+
+The long-lived dev environment (`tools/dev-deploy/`) is single-tenant:
+one live deployment, redeployed on every merge into `development`.
+While a PR is open the dev environment stays on whatever was last
+merged — pushes to `feature/*` only fire the test workflows
+(`go-unit`, `ui-test`, `integration`), not `dev-deploy.yaml`.
+
+To preview an unmerged feature branch on the shared dev environment,
+trigger `dev-deploy.yaml` manually from the Gitea UI
+(**Actions → Deploy · Dev → Run workflow**) and pick the feature ref.
+The deploy is idempotent: the next merge into `development` simply
+overwrites whatever the manual dispatch left behind.
+
 ## Per-stage CI gate
 
 Every completed stage from any `PLAN.md` (per-service or `ui/PLAN.md`)
@@ -72,10 +86,6 @@ short version:
 4. Only after every workflow that fired is `success` may the stage be
    marked done in the corresponding `PLAN.md`.
 
-`tools/local-ci/` is now an opt-in fallback for testing workflow
-changes without `gitea.lan` (offline iterations, runner-isolation
-debugging). It is no longer required for the per-stage gate.
-
 ## Decisions during stage implementation
 
 Stages from `PLAN.md` produce decisions. Those decisions never live in a
@@ -102,18 +112,22 @@ The existing codebase of `galaxy/<service>` may be modified or extended when a
 plan stage requires it. All such changes must be covered by new or updated tests
 and reflected in documentation when they affect documented behavior.
 
-## Pre-production migration rule
+## Migrations
 
-The platform is not yet in production. Schema changes for `backend` go
-into the existing `backend/internal/postgres/migrations/00001_init.sql`
-file rather than into new `00002_*`-prefixed files. Local databases and
-integration test harnesses are recreated from scratch on every pull.
+Schema changes for `backend` go into a new `0000N_*.sql` file under
+`backend/internal/postgres/migrations/` with a monotonically increasing
+prefix. `00001_init.sql` is the historical baseline and stays
+immutable; every subsequent change is its own additive migration with
+matching Up/Down sides. `pressly/goose/v3` (embedded into the backend
+binary) applies pending migrations on startup, so the long-lived dev
+environment picks up schema deltas without a manual reset.
 
-**This rule is removed before the first production deployment.** From
-that point on every schema change becomes a new migration file with a
-monotonically increasing prefix, and `00001_init.sql` becomes immutable
-history. See `backend/internal/postgres/migrations/README.md` for
-details.
+Before the first production deployment the migration chain may be
+squashed back into a single fresh `00001_init.sql` for a clean slate;
+plan that work as an explicit task when it lands. See
+`backend/internal/postgres/migrations/README.md` for the local
+authoring conventions (file naming, transactional vs. non-transactional
+sections, backward-compatible deletes, rollback expectations).
 
 ## Documentation discipline