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
+**Place it, do not retire it.** Operator decision:
-not one. Options: part of S4, a sixth level, or cross-cutting.
 
-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

docs/credential-lane-lifecycle-runbook.md

@@ -46,8 +46,8 @@ secret value ever appears in Git, State Hub, chat, prompts, or shell history.
   `force-sync`), then restart `deploy/actcore-worker` and
   `deploy/actcore-event-router`, or activity-core emission silently starts
   failing with 401s on the next run.
-- `GITEA_BACKEND_TOKEN` is a scoped Gitea token for service user
+- `GITEA_BACKEND_TOKEN` is a scoped Forgejo token for service user
-  `issue-core-svc`; rotating it means minting a new token in Gitea first,
+  `issue-core-svc`; rotating it means minting a new token in Forgejo first,
   then updating OpenBao — order matters, or ingestion breaks between steps.
 
 ## Lane: llm-connect OpenRouter provider key (`CCR-2026-0003`)

docs/openbao.md

@@ -124,14 +124,14 @@ unseal keys and initial root token. Treat this as a break-glass event.
 ### Setup Operator And King Credential
 
 The initial accountable setup operator/contact is `tegwick`
-(`bernd.worsch@gmail.com`), with Gitea identity `tegwick`. This identity can
+(`bernd.worsch@gmail.com`), with Forgejo identity `tegwick`. This identity can
 assemble early infrastructure, receive notifications, and operate day-to-day
-Git/Gitea workflows, but it is not the desired long-term platform root of
+Git/Forgejo workflows, but it is not the desired long-term platform root of
 trust.
 
 The actual platform-root target is a separate king credential created through
 the NetKingdom bootstrap path before OpenBao becomes live secret custody. Email
-may receive notifications, but Gitea, Git, State Hub, chat, tickets, shell
+may receive notifications, but Forgejo, Git, State Hub, chat, tickets, shell
 history, and email must not store or transfer OpenBao unseal keys, root tokens,
 private keys, OTP seeds, recovery codes, or screenshots of secret output.
 
@@ -316,7 +316,7 @@ Initial auth model:
 
 | Actor | Method | Notes |
 |-------|--------|-------|
-| Setup operator/contact | Gitea `tegwick` / `bernd.worsch@gmail.com` | low-trust assembly and notifications; not platform root of trust |
+| Setup operator/contact | Forgejo `tegwick` / `bernd.worsch@gmail.com` | low-trust assembly and notifications; not platform root of trust |
 | King credential | NetKingdom custody record for dedicated platform-root identity | accountable bootstrap/recovery authority; not a Git or email secret store |
 | Bootstrap operator | one-time root token | only for initial audit, mounts, auth, policies, and non-root token creation |
 | Platform operator | token with `platform-admin` | temporary until NetKingdom OIDC/admin integration is ready |

docs/whynot-design-npm-publish-handoff.md

@@ -17,10 +17,10 @@ This is the next-session handoff for `CCR-2026-0001` and the
 - Bound IAM group: `whynot-design`
 - Secret path: `platform/workloads/coulomb/whynot-design/npm-publish`
 - Field: `NPM_AUTH_TOKEN`
-- Token source: Gitea package token for
+- Token source: Forgejo package token for
   `https://forgejo.coulomb.social/api/packages/coulomb/npm/`
 
-The operator reported that the Gitea token was generated and stored in OpenBao.
+The operator reported that the Forgejo token was generated and stored in OpenBao.
 Using the temporary operator token only for non-secret infrastructure work, Codex
 confirmed that the policy exists, the OIDC role exists with the whynot-design
 binding and redirect URIs, the secret metadata has the expected catalog id, and