Move Gitea deploy surface into forge

docs/first-migration-plan.md

@@ -2,14 +2,15 @@
 
 Date: 2026-06-05
 
-Status: Phase 1 is underway. The remote repository exists and is pushed, so the
-earlier Gitea API blocker no longer applies.
+Status: Phases 1 through 3 are complete as file ownership moves. No live Helm
+deploy, SOPS decryption, or Kubernetes apply was run.
 
 This plan starts the extraction of forge ownership from `railiance-apps` into
 `railiance-forge` without changing the live Gitea deployment.
 
 The rule for the first migration is simple: move knowledge and read-only
-operator entry points before moving deploy-capable configuration.
+operator entry points before moving deploy-capable configuration. That sequence
+has now been followed.
 
 ## Goals
 
@@ -63,18 +64,18 @@ Initial `railiance-forge/Makefile` targets:
 - `check-tools`: minimal local tool check for `kubectl`, `helm`, `sops`, and
   optional `tea`.
 
-Do not add `gitea-deploy` in this phase.
+`gitea-deploy` was intentionally deferred until Phase 3.
 
 Validation:
 
 - Targets are read-only.
 - Targets either succeed or fail with clear missing-tool messages.
-- `railiance-apps` still owns deploy-capable Gitea targets during the
-  transition.
+- `railiance-apps` still has compatibility wrappers during the transition.
 
 ## Phase 3 - Deploy-Capable Target Review
 
 Move deploy-capable Gitea ownership only after Phase 1 and Phase 2 are reviewed.
+This is now complete as a file move.
 
 Candidate moves:
 
@@ -123,5 +124,5 @@ aligned with `origin/main`.
 
 ## Next Recommended Action
 
-Complete Phase 1 documentation canonicalization and Phase 2 read-only operator
-targets, then review the deploy-capable Gitea file move separately.
+Complete Phase 4 S5 scope cleanup and decide when compatibility wrappers in
+`railiance-apps` can be retired.