feat(workflow): Gitea-Wiki als generierter Spiegel von docs/ (#192)

Konverter .gitea/scripts/wiki_mirror.py, Push-Skript wiki-push.sh, Job wiki-mirror in release.yml, Dispatch-Workflow wiki-mirror.yml und --check-Schritt in ci.yml. Version 9.0.0-beta.13.

Files changed:
- .gitea/scripts/wiki-push.sh
- .gitea/scripts/wiki_mirror.py
- .gitea/workflows/ci.yml
- .gitea/workflows/release.yml
- .gitea/workflows/wiki-mirror.yml
- CHANGES.md
- README.md
- VERSION
- docs/dev/development.md
- tools/chemenu/tests/test_wiki_mirror.py

Co-Authored-By: Claude Code <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

docs/dev/development.md

@@ -20,6 +20,7 @@ them. The reason is a comment at `dist_cmd.DOCS_DEV_ONLY`, so that a later sessi
   - [A release feed in a non-public repository](#a-release-feed-in-a-non-public-repository)
 - [The release workflow](#the-release-workflow)
 - [The CI half](#the-ci-half)
+  - [The Gitea wiki](#the-gitea-wiki)
   - [How much of the stack the suite reaches](#how-much-of-the-stack-the-suite-reaches)
 - [Stack development as a session type of its own](#stack-development-as-a-session-type-of-its-own)
 <!-- /wikitool:toc -->
@@ -155,6 +156,10 @@ the order a session actually goes through it:
    cause, publish, and start `release.yml` on `main` via `workflow_dispatch`. The check for an
    existing release prevents a second one.
 
+   A second job, `wiki-mirror`, runs after a suffix-free release and mirrors the docs of the
+   release tree into the Gitea wiki ([The Gitea wiki](#the-gitea-wiki) below). It is a job of its
+   own, so a failing mirror leaves the release and its tag standing and marks only itself red.
+
 The three check commands are in step 3 above; what each of them checks is in
 [tools/CONTRACT.md](../../tools/CONTRACT.md), where `docs verify` holds it against the actual
 CLI. It is deliberately **not** repeated here: a second description of the same commands is
@@ -170,7 +175,8 @@ runs the test suite, `docs verify`, `instructions verify` and a complete `setup-
 replay: a locally built release tarball, the preflight script with `--archive` in an empty
 directory, then the instruction's steps - the same path a new user actually takes, just without
 the download. `.gitea/workflows/nightly.yml` is the drift check against time rather than against
-a commit. `.gitea/workflows/release.yml` is step 6 above.
+a commit. `.gitea/workflows/release.yml` is step 6 above, and `.gitea/workflows/wiki-mirror.yml`
+refills the Gitea wiki by hand (see below).
 
 Three more workflows carry the live tests of the tracker adapters (Super Productivity, CalDAV):
 `ci.yml` runs the CalDAV half in a step of its own against Radicale as a process,
@@ -182,6 +188,35 @@ repository by hand. What the suite writes, how to run it against a tracker of yo
 a red run means is in
 [instructions/dev/tracker-testing.md](../../instructions/dev/tracker-testing.md).
 
+### The Gitea wiki
+
+The wiki of `torben/chemenu` shows the documentation of the **latest release**. It is generated
+and never edited: every run replaces its whole content, so a change made in the wiki is gone at
+the next mirror, and nothing but CI writes to it (a push to the wiki repository by a session
+would sit next to `publish`, which AGENTS.md invariant 5 forbids).
+
+`.gitea/scripts/wiki_mirror.py` converts a tree into the wiki's page set: every `*.md` under
+`docs/` (the `dev/` pages included), plus `README.md` as `Home` and `INSTALL.md` as `Install`.
+Wiki pages in sub-directories are not listed reliably, so the names are flat: the path below
+`docs/` with `.md` dropped, each segment capitalised and joined by `-`
+(`docs/how-to/ingest-a-source.md` becomes `How-to-Ingest-a-source`; a `README.md` stands for its
+directory). Two sources that would get the same name, compared without case, abort the run.
+Relative links between mirrored files become wiki page names, relative links to anything else
+become links to that file at the release tag, and a link whose target does not exist aborts the
+run. A `_Sidebar` is generated, and every page opens with a line saying which file at which
+version it came from. `.gitea/scripts/wiki-push.sh` then makes the wiki repository hold exactly
+that output - a page the converter no longer produces is removed - and does not commit when
+nothing changed.
+
+Two things start it: the `wiki-mirror` job of `release.yml`, after each release (never for a
+candidate), and `.gitea/workflows/wiki-mirror.yml` by hand with `workflow_dispatch`. The manual
+workflow takes a `tag` (default: the latest release) and runs the converter and push script of
+`main` against that tag's tree. Use it to fill the wiki before the first release that carries the
+job, or to catch up a mirror that failed after its release was published. `ci.yml` runs
+`wiki_mirror.py --check` against the working tree on every push, so a link the mirror could not
+resolve fails there rather than at the release. The scripts live under `.gitea/`, which
+`dist export` does not copy, so none of this reaches an instance.
+
 ### How much of the stack the suite reaches
 
 Coverage is measured in CI - `pytest --cov`, config in `tools/.coveragerc`, HTML and XML