fix(ci): give the nightly-windev issue body a reachable run link (TST-25 Check 6)

Exercising TST-25 acceptance Check 6 end-to-end showed the on-failure issue
step works — it has filed an issue on every red nightly since 2026-07-17
(#126-#139) — but that every one of those issues links `http://gitea:3000`,
the runner-internal origin Gitea hands the runner. That URL is correct for
the issue-creation API call (the job container resolves `gitea` only on the
docker network and has no LAN egress to the public origin) and unreachable
for anyone clicking out of the issue.

Keep `github.server_url` for the API call; add a `PUBLIC_SERVER_URL` job env
used only for the browser-facing link in the body. Verified with a
forced-failure probe run (677) whose issue (#140) carries a public link that
returns 200.

Also records Check 6 as done in scripts/ci/README.md and corrects the
2026-07-13 tracking entry that wrote the check off as abandoned.

scripts/ci/README.md

@@ -53,6 +53,16 @@ first, then merge.
 - Unreachable-host red: point at a bogus port / stop sshd, confirm the job fails fast, not hangs.
 - Concurrency: push two branches back-to-back, confirm the second remote run waits on the lock.
 - Nightly: trigger the schedule path, confirm `live` runs and a forced failure opens an issue.
+  **Done 2026-08-10** (Check 6). Verified two ways: (a) production — every red nightly since
+  2026-07-17 has auto-filed an issue (#126–#139) authored by the `gitea-actions` bot, e.g. run 672
+  → issue #139, with the built-in token masked to `***` in the job log; (b) a forced-failure probe
+  on the throwaway branch `test/tst25-check6-nightly-issue` (run 677 → issue #140, since closed and
+  the branch deleted), which reproduced the job shape with `exit 1` in place of the live step and
+  confirmed the `if: failure()` step fires, the token carries issue-write, and the payload is
+  well-formed. The probe also caught the one defect: `${{ github.server_url }}` is the
+  runner-internal `http://gitea:3000`, so the run link in the issue body was unreachable from a
+  browser — the body now uses the `PUBLIC_SERVER_URL` job env instead (the API call still targets
+  `github.server_url`, which is what the job container can resolve).
 - Confirm no key material appears in job logs.
 
 ## Degraded mode