docs: SSOT for the Gitea CI pipeline and automated alpha releases

docs/ci-and-releases.md documents what happens on a push to main, why Gitea
rather than GitHub (billing-blocked, private repo, and Forgejo ships no hosted
runners), both runners and their prerequisites, the release/manifest layout,
and how to verify a release with the Lane=Live install test.

Its landmine table is the part worth keeping: every row cost a red pipeline —
Node for JS actions, setup-dotnet unmirrored on data.forgejo.org, the
zombie-task timeout caused by run-release-gate.ps1 redirecting child output,
an en-SE runner locale breaking 40 tests on decimal commas, DAT tests missing
their InstalledDat lane tag, parallel-load timing flakes, and the Avalonia
compositor threading failure that must NOT be 'fixed' by de-async-ing the test.

Also records the culture finding: config, parsing and the wire are all
invariant-safe, so US and European installs behave identically; only
diagnostic strings follow the current culture.

Cross-linked from docs/README.md and release-gate.md, which keeps ownership of
the local bounded gate.

docs/release-gate.md

@@ -72,6 +72,14 @@ The JSON summary records the exact test filter. Environment-dependent,
 diagnostic, manual, and known-failure results must be published as their own
 lane and must never be added to the hermetic pass headline.
 
+## Continuous integration
+
+This document owns the LOCAL gate. Pushes to `main` are gated on self-hosted
+runners and publish alpha releases — see
+[`ci-and-releases.md`](ci-and-releases.md). Note that CI deliberately does NOT
+invoke `run-release-gate.ps1`: that script redirects child output to log files,
+and Forgejo fails a task that stops reporting as a zombie.
+
 ## Non-hermetic test lanes
 
 Installed-DAT tests require an explicit opt-in and a retail DAT directory: