Clarify Gitea verification failure diagnostics

docs/CURRENT_STATUS.md

@@ -17,6 +17,17 @@ open mode gates.
 
 ## Current checkpoint and work
 
+**Gitea verification diagnostics — 29 October. Partial.** The approved
+runner network configuration was already applied, and later runs reached the
+application and published images. Run #85 failed in administrator acceptance
+when a fetch threw before its response. Its logged 403 was the previous
+completed request, a possible expected denial, not proof of an authorization
+failure; the exception's cause was not recorded. Acceptance diagnostics now
+distinguish request exceptions from the last completed response and report only
+sanitized details; the security checks are unchanged. Two focused diagnostic
+cases pass. Run #86 was building its container at the last check; the updated
+diagnostics still need CI verification.
+
 **Truthtrance ally funding — 29 October. Prototyped / Partial.**
 Supported quiet Basic Bidding and Shipment/Movement questions can bind a future
 funding update to the respondent's current mutual ally. Existing escrow alone

docs/TRUENAS.md

@@ -8,8 +8,8 @@ runtime prototype does not change public release or rules-mode gates.
 
 ## Checkpoint images
 
-The source repository is moving to [Gitea](https://git.juiced.computer/admin/Dune).
-Its `.gitea/workflows/container.yml` is intended to build and verify checkpoint
+The source repository is hosted on [Gitea](https://git.juiced.computer/admin/Dune).
+Its `.gitea/workflows/container.yml` builds and verifies checkpoint
 images on pushes to `main`. Configure the Gitea Actions variables
 `DUNE_CONTAINER_IMAGE` for the full registry image name and
 `DUNE_REGISTRY_USERNAME` for the registry account; supply the registry token as
@@ -17,14 +17,15 @@ the `CONTAINER_REGISTRY_TOKEN` Actions secret. The default image name is
 `git.juiced.computer/admin/dune`. Registry access and image visibility depend
 on the actual Gitea package settings; do not assume anonymous pulls work.
 
-No Gitea runner has been registered and no Gitea image build has succeeded yet.
-A source push is therefore not a verified container image or a deployment.
-Register and configure an `ubuntu-latest` runner whose job environment has a
-working Docker CLI, daemon and Buildx, plus network access to actions, npm and
-container images. Configure registry access, then verify the
-workflow and its published image before considering a manual NAS update. The
-existing Compose configuration continues to reference the GHCR image until a
-separately verified migration is applied at a safe point.
+An `ubuntu-latest` Gitea runner is configured. On 29 October 2026, run #83
+verified and published commit `b18a7674702b92b6988b00cbde6212fa3b66b74a`.
+The registry shows its immutable `sha-b18a7674702b92b6988b00cbde6212fa3b66b74a`
+tag and `checkpoint` with the same digest. Run #85 failed before publication,
+so a source push still does not by itself establish a verified image or a
+deployment. For each checkpoint, verify the relevant workflow run and its
+published revision before considering a manual NAS update. The existing TrueNAS
+deployment and Compose configuration continue to reference the GHCR image; a
+Gitea publication does not migrate them.
 
 The previous GitHub workflow, `.github/workflows/container.yml`, builds a
 production image using the lockfile on GitHub pushes. Types, lint and offline