docs: sync project guides to the new CI flow

Aligns the project guides with the branching/CI/environment changes
landed in the previous commits:

- CLAUDE.md: per-stage CI gate now closes against gitea.lan; describes
  the main/development/feature/* flow and the workflow surface
- docs/ARCHITECTURE.md: new section 18 "CI and Environments" covering
  branches, workflows, and the local-dev / dev-deploy / local-ci
  triad; section numbering shifted accordingly
- tools/local-ci/README.md: marked as fallback (offline / runner
  isolation only)
- tools/local-dev/README.md and ui/README.md: cross-link to
  tools/dev-deploy/ for production-shaped testing

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

tools/local-ci/README.md

@@ -1,9 +1,17 @@
-# Local Gitea CI
+# Local Gitea CI (fallback)
+
+> **Status:** fallback / opt-in. The primary CI target is now
+> `gitea.lan` with its host-mode `act_runner`. The per-stage CI gate
+> closes against `gitea.lan`, not against this stack. Use this
+> directory when you want to validate `.gitea/workflows/*` without
+> reaching `gitea.lan` — for example, when iterating on a workflow
+> file from a flight without LAN access — or when isolating a runner
+> issue from production-shaped infrastructure.
 
 Self-contained Gitea + Actions runner for verifying
-`.gitea/workflows/*` honestly before pushing to a real Gitea instance.
-Runs natively on arm64 (Apple Silicon) — every image below has an
-arm64 variant, so Docker pulls the right architecture and the runner
+`.gitea/workflows/*` honestly before pushing to `gitea.lan`. Runs
+natively on arm64 (Apple Silicon) — every image below has an arm64
+variant, so Docker pulls the right architecture and the runner
 executes workflow steps without QEMU emulation.
 
 ## Prerequisites

tools/local-dev/README.md

@@ -10,11 +10,15 @@ FlatBuffers wire, every authenticated call verifies the response
 signature against the dev keypair, and every email passes through
 Mailpit's web UI for inspection.
 
-This stack is **not** a CI gate (that role belongs to
-[`tools/local-ci/`](../local-ci/README.md), which boots a Gitea +
-Actions runner and replays workflow files). The two stacks are
-independent and can coexist on the same machine; they bind different
-ports and use different networks.
+This stack is **not** a CI gate (the per-stage CI gate now lives on
+`gitea.lan`; see project-level `CLAUDE.md`). It is also distinct from
+the **long-lived dev environment** at
+[`tools/dev-deploy/`](../dev-deploy/README.md), which is redeployed on
+every merge into `development` and is reachable as
+`https://www.galaxy.lan` / `https://api.galaxy.lan`. The three stacks
+(`tools/local-dev/`, `tools/dev-deploy/`, and the fallback
+`tools/local-ci/`) coexist on the same host because every name —
+compose project, container, network, volume — is distinct.
 
 ## Bring it up