converters: Testkorpus und Harness ziehen nach torben/chemenu-testfiles, Workflow Converters mit Pfad-Trigger, Release-Gate (#232); 10.1.0-beta.2

Files changed:
- .gitattributes
- .gitea/workflows/converters.yml
- .gitea/workflows/release.yml
- .gitignore
- CHANGES.md
- VERSION
- docs/dev/development.md
- instructions/dev/dev-setup.md
- instructions/dev/publish-and-ci.md
- instructions/dev/testing-conventions.md
- testfiles/README.md
- testfiles/mail/github-outlook.msg
- testfiles/mail/github-roundcube.eml
- testfiles/mail/gog-outlook.msg
- testfiles/mail/gog-roundcube.eml
- testfiles/mail/gog-roundcube.eml.expect
- testfiles/mail/tldr-outlook.msg
- testfiles/mail/tldr-roundcube.eml
- testfiles/office/excel-artificial.xlsx
- testfiles/office/excel-business.xlsx
- testfiles/office/excel-business.xlsx.expect
- testfiles/office/excel-science.xlsx
- testfiles/office/pptx-baseline.pptx
- testfiles/office/pptx-master.pptx
- testfiles/office/pptx-objects.pptx
- testfiles/office/word-complex.docx
- testfiles/office/word-simple.docx
- testfiles/pdf/einstein-dissertation.pdf
- testfiles/pdf/ifg.pdf
- testfiles/pdf/nist-ai-rmf.pdf
- testfiles/pdf/nist-ssdf-genai.pdf
- testfiles/zip/archive.zip
- tools/chemenu/tests/test_raw_derive_testfiles.py

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

docs/dev/development.md

@@ -40,8 +40,20 @@ Then have the agent run `instructions/bootstrap.md`: the preflight, then
 and how `dist export` runs as a test tool - is
 [instructions/dev/dev-setup.md](../../instructions/dev/dev-setup.md).
 
-Real documents for `raw derive` live in [testfiles/](../../testfiles/README.md) and are
-committed, so CI derives them too. The repository is public: that README says what may go in.
+Real documents for `raw derive` do not live in this repository. The corpus and its test harness
+are the private repository `torben/chemenu-testfiles`, cloned by hand into `testfiles/` (gitignored
+here, deliberately not a submodule, so a clone without access works unchanged):
+
+```bash
+git clone ssh://git@gitea.nehmer.net:10101/torben/chemenu-testfiles.git testfiles
+cd tools && .venv/bin/python -m pytest -c pytest.ini ../testfiles/harness
+```
+
+It is private because the corpus is large (some 76 MB; one book takes 48 s per derivation) and
+holds material that may not sit in a public repository, such as publishers' books and vendors'
+documents. Without the clone, `pytest` runs unchanged and the real-document tests are simply not
+there; the README of the private repository says what is in it, what each file's origin is and
+whether it could be public. The tests run in their own workflow, see [The CI half](#the-ci-half).
 
 What a clone has and an instance does not:
 
@@ -181,6 +193,18 @@ the download. `.gitea/workflows/nightly.yml` is the drift check against time rat
 a commit. `.gitea/workflows/release.yml` is step 6 above, and `.gitea/workflows/wiki-mirror.yml`
 refills the Gitea wiki by hand (see below).
 
+`.gitea/workflows/converters.yml` runs the converters against the real documents of the private
+repository (the clone above, run with the checkout's `tools/.venv`). It starts by itself on a push
+to `main` that touches the converter surface - `tools/chemenu/filters/`, `raw/derive.py`,
+`raw/accept.py`, `tests/test_raw_derive*.py`, `tests/binary_formats.py`, `tools/requirements.txt`
+and the workflow itself - and by hand (`workflow_dispatch`), which is how to run it after a change
+in the private repository alone: a push there starts nothing here. It always tests `main` of the
+private repository, so a converter change that alters an expected output is two commits, the
+private one first. Before a release without suffix, `release.yml` runs the same steps as a job its
+release job waits for; a red harness ends the run before a release or a tag exists, and a
+`-beta.N` candidate skips it. The job reads the private repository with the per-job token; if
+that instance ever stops allowing this, the workflow's header names the 1Password fallback.
+
 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,
 `tracker-live.yml` runs nightly and covers both providers, and `sp-live-image.yml` builds the