Update Gitea prose to Forgejo; place forge; record ArgoCD as an open decision

Gitea has been replaced by Forgejo. Updates prose mentions in docs/ while
deliberately preserving live names that a blind sweep would have broken:
GITEA_BACKEND_TOKEN is a provisioned OpenBao field in CCR-2026-0002, GITEA_URL
is a Makefile variable, and gitea-db is a running cnpg cluster. Capitalisation
discriminates prose from identifiers. Archived workplans are left as historical
record.

Blueprint 5.2: forge placement decided - workload to rapp-forgejo, layer
responsibility to S4 railiance-enablement, which already declares the handoff
contract and gains its first concrete owned responsibility.

Blueprint 5.6: whether Railiance should use ArgoCD at all is recorded as an open
decision rather than acted on by removing mentions. S3 runs four live ArgoCD
Applications plus AppProjects, and the two most recent commits here add more, so
deleting the documentation would describe a system that does not exist. The
question is real; it needs a decision and a migration, not a docs edit.

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

ArchitectureBlueprint.md

@@ -74,7 +74,7 @@ stack rather than inside it.
 | evidence plane | `railiance-telemetry` | metrics, logs, traces, alerting — the substrate other layers emit into (**OPEN** placement, §5.1) |
 | architecture | `railiance-master` | repo taxonomy, framework ADRs, boundary rules, vocabulary |
 | ecosystem graph | `railiance-fabric` | repo → service → capability → interface → dependency model |
-| forge | `railiance-forge` | source hosting, registries, automation runners (**OPEN** placement, §5.2) |
+| forge | `railiance-forge` | source hosting, registries, automation runners — **being placed** (§5.2): workload → `rapp-forgejo`, layer responsibility → S4 |
 
 ### The layering contract
 
@@ -156,12 +156,23 @@ by all of them. Is it an S3 platform capability (it runs stateful services and
 is consumed by others), or a Quality-dimension concern outside the Stack
 dimension? Stated explicitly at seeding so it does not drift into §5.2's state.
 
-### 5.2 Where does `railiance-forge` sit? → `railiance-master`
+### 5.2 Where does `railiance-forge` sit? → **DECIDED 2026-08-11**
 
-It calls itself "the forge layer", but the stack has five levels and forge is
-not one. Options: part of S4, a sixth level, or cross-cutting.
+**Place it, do not retire it.** Operator decision:
 
-Note the retirement hypothesis was **tested and rejected**: `railiance-forge`
+- the Forgejo **workload** becomes `rapp-forgejo` (a managed workload package)
+- the **layer responsibility** — runner placement and labels, registry
+  retention, artifact lifecycle, package credentials — folds into **S4
+  `railiance-enablement`**, which already declares the handoff contract for
+  exactly these concerns
+
+This also gives S4, currently the widest aspiration-to-reality gap in the
+family, its first concrete owned responsibility.
+
+Implementation is `railiance-master` and `railiance-forge` territory; this
+blueprint records the decision, not the migration.
+
+The retirement hypothesis was **tested and rejected**: `railiance-forge`
 and `helix-forge` are different lineages. `helix-forge` is methodological
 (capability-first ecosystem, OAS dimensions, VSM vocabulary); `railiance-forge`
 is operational (`helm/`, `manifests/`, `releases/`, `runner/`, live workplan on
@@ -186,6 +197,23 @@ to `railiance-master` (`04c776c4`, amended `f88f938d`).
 - delete the local `~/railiance-bootstrap` directory, which is a mis-cloned copy
   of `railiance-cluster.git`
 
+### 5.6 Does Railiance use ArgoCD at all? → **OPEN**, `railiance-master`
+
+Raised by the operator 2026-08-11: GitOps-by-ArgoCD may be Helix Forge tooling
+rather than a Railiance concern, or may not be needed at all.
+
+**This cannot be resolved by editing documentation.** S3 currently runs ArgoCD
+as its live deployment mechanism: four Application manifests
+(`external-secrets`, `issue-core`, `openbao-secretstore`, `target-revenue`),
+AppProjects under `argocd/bootstrap/`, `docs/argocd-gitops.md`, and the two most
+recent commits in this repo add ArgoCD Applications. Removing mentions while the
+Applications remain would make the documentation describe a system that does not
+exist.
+
+The real question is an architecture decision — *should S3 deploy via ArgoCD?* —
+with a migration attached if the answer is no. Until it is taken, mentions stay
+because they are accurate.
+
 ### 5.5 Rapp granularity and composition → decided, implementation open
 
 Grouped by bounded context; members declared explicitly; grouping legitimate