fix: complete self-hosted staging identity integration

Align staging deployment, authentication, and admin access with the self-hosted identity boundary, including regression coverage and deployment diagnostics.

debug-npm-integrity-failure.md

@@ -0,0 +1,34 @@
+# Debug Session: npm-integrity-failure
+
+Status: [OPEN]
+Started: 2026-07-29
+
+## Symptom
+Gitea staging Web image build fails during `npm ci` for `server-only@0.0.1` with `EINTEGRITY`. The downloaded 477-byte tarball digest differs from `package-lock.json`.
+
+## Constraints
+- Do not modify business logic during evidence collection.
+- Do not expose registry credentials or application secrets.
+- Preserve the current staging deployment until a verified image and migration are ready.
+
+## Hypotheses
+1. The lockfile integrity for `server-only@0.0.1` is incorrect.
+2. The Runner network path receives corrupted or substituted registry bytes.
+3. BuildKit/npm cache contains a corrupted tarball and retries reuse it.
+4. A proxy or registry override affects the Runner despite the npmjs URL in logs.
+5. The upstream tarball changed while registry metadata and lockfile diverged.
+
+## Evidence
+- `package-lock.json` expects `server-only@0.0.1` integrity ending in `GNSg==`.
+- The failed Gitea task downloaded 477 bytes and computed integrity ending in `iswNA==` twice.
+- Current registry metadata reports integrity ending in `iswNA==`.
+- A direct download from `registry.npmjs.org` on xiaoxin is 477 bytes and computes the same integrity ending in `iswNA==`.
+- A clean Docker Hub probe was blocked by an unrelated Docker Hub timeout.
+
+Conclusion: H1/H5 confirmed. The locked integrity is stale relative to the current tarball. H2/H3/H4 are rejected by the consistent direct-download and metadata evidence.
+
+## Fix
+Update only the stale `server-only@0.0.1` integrity entry in `package-lock.json` to the digest proven by registry metadata and direct download.
+
+## Verification
+Pending post-fix workflow.