Correct stale Gitea current-state claims to Forgejo

Forgejo has replaced Gitea as the forge. Updates SCOPE.md Current State,
AGENTS.md and .claude/rules/repo-identity.md, which still described Gitea as
the operational forge.

Deliberately NOT changed, because they are accurate rather than stale:
- migration and coexistence prose in docs/forgejo-on-railiance01.md,
  docs/forge-source-of-truth-decision.md and the capability registry, where
  Gitea is the thing being migrated from
- gitea-charts/gitea 12.5.0, the real Helm chart Forgejo deploys from
- gitea-db, a running CNPG cluster, and the gitea- prefixed doc filenames in
  railiance-forge, which still exist under those names

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

.claude/rules/repo-identity.md

@@ -1,4 +1,4 @@
-**Purpose:** OAS S5 Workloads & Experience Endpoints — application Helm releases, Gitea, coulomb services
+**Purpose:** OAS S5 Workloads & Experience Endpoints — application Helm releases, Forgejo, coulomb services
 
 **Domain:** financials
 **Repo slug:** railiance-apps

AGENTS.md

@@ -2,7 +2,7 @@
 
 ## Repo Identity
 
-**Purpose:** OAS S5 Workloads & Experience Endpoints — application Helm releases, Gitea, coulomb services
+**Purpose:** OAS S5 Workloads & Experience Endpoints — application Helm releases, Forgejo, coulomb services
 
 **Domain:** financials
 **Repo slug:** railiance-apps

SCOPE.md

@@ -125,16 +125,16 @@ lessons into reusable S5 app release patterns.
 
 ## Current State
 
-- Gitea is deployed and operational as the current forge. Its deploy-capable
-  Helm/SOPS/manifests now live in `railiance-forge`; this repo no longer keeps
-  Gitea deploy/status wrappers or registry pointer docs.
-- The Gitea container and Python package registry paths are verified. Canonical
+- Forgejo is deployed and operational as the current forge, having replaced
+  Gitea. Its deploy-capable Helm/SOPS/manifests live in `railiance-forge`; this
+  repo no longer keeps forge deploy/status wrappers or registry pointer docs.
+- The container and Python package registry paths are verified. Canonical
   registry operating docs live in `railiance-forge`; S5 runbooks link to those
   docs directly when app releases consume forge artifacts.
 - The final source-of-truth decision for forge ownership is recorded in
   `docs/forge-source-of-truth-decision.md`.
 - The `issue-core` migration blocker is closed: `issue-core==0.2.0` is
-  published to the Gitea PyPI registry, and the `vergabe-teilnahme` lock in its
+  published to the forge PyPI registry, and the `vergabe-teilnahme` lock in its
   source repo resolves it from the registry rather than a sibling checkout.
 - `vergabe-teilnahme` is represented as a local Helm chart plus values,
   ingress, Makefile targets, and an operator runbook.
@@ -255,7 +255,8 @@ keywords: [operator, runbook, sops, cnpg, dry-run, smoke-test, deployment]
 2. Read `INTENT.md` for the stable purpose of the S5 layer.
 3. Read this file for scope and boundaries.
 4. Read the active files in `workplans/`.
-5. For Gitea registry work, use the forge-owned docs directly:
+5. For forge registry work, use the forge-owned docs directly (filenames still
+   carry the legacy `gitea-` prefix):
    `/home/worsch/railiance-forge/docs/gitea-container-registry.md` and
    `/home/worsch/railiance-forge/docs/gitea-package-registry.md`.
 6. For a new S5 app release, start with