docs(prs): the gitea-default-clone-url PR-doc

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/prs/2026-09-04-PR#21-gitea-default-clone-url.md

@@ -0,0 +1,30 @@
+> **WARNING:** This document describes only the change applied in this PR.
+> It may already be outdated once the next PR is merged.
+> Historic PR-documentation is not maintained along with new PRs — treat it as a snapshot, not as current documentation.
+
+## The Problem
+
+The repository's home is `https://git.javagil.de/mi/werkator.git` since the move to the own Gitea instance,
+but `tools/remote` still defaulted `WERKATOR_REPO_URL` to the GitHub mirror.
+
+The mih09 production instance was cloned from that mirror and consequently watched a `main` that nobody pushes to any more:
+it kept reporting the last GitHub state as green while three merged pull requests sat unbuilt on the real `main`.
+The failure that started this — a flaky test already fixed on Gitea's `main` — could not be re-verified live,
+because the instance had no way to see the fix.
+
+## Non-Goals
+
+- The existing clone on mih09 is not touched by this change; its remote was repointed by hand (`git remote set-url`), and `repo-init` skips an existing clone.
+- The generic placeholder URLs in `docs/deployment.md` stay as they are — they describe cloning *any* watched repository, not werkator's own.
+- No decision about mirroring to GitHub; the mirror simply stops being the source an instance builds from.
+
+## The Solution
+
+`REPO_URL` in [tools/remote](../../tools/remote) defaults to the Gitea URL, and the usage comment says so.
+
+The value stays overridable via `WERKATOR_REPO_URL` in the instance's env file,
+so an installation that deliberately watches a different remote is unaffected.
+Anonymous HTTPS works against Gitea exactly as it did against GitHub, so no deploy key or token is involved.
+
+Note that pull requests opened via AGit-Flow create no branch in Gitea,
+so an instance watching this remote sees `main` only — branch builds require pushing real branches.