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

instructions/dev/publish-and-ci.md

@@ -7,7 +7,8 @@ description: How a stack change is published and how its CI run is waited for -
 
 The local checks cover what they cover on this machine; CI covers the same checks plus a full
 `setup-instance.md` replay against a fresh `dist export` (`.gitea/workflows/ci.yml`). A green run
-on the published commit is therefore the end of the checked stretch of a work package, not a
+on the published commit - and, for a converter change, a green `Converters` run (step 3) - is
+therefore the end of the checked stretch of a work package, not a
 formality after it - which is why waiting for it belongs to the phase that wrote the code
 (`stack-build`), and a red run sends the work back there rather than into the closing phase.
 
@@ -54,6 +55,17 @@ formality after it - which is why waiting for it belongs to the phase that wrote
    - Keep the polling out of the main context where the harness allows it - a background
      command or a fork - so a long wait does not fill the session with run listings.
 
+   **Converter changes have a second run.** When the published commit touches the converter
+   surface - `tools/chemenu/filters/`, `tools/chemenu/commands/raw/derive.py` or `accept.py`,
+   `tools/chemenu/tests/test_raw_derive*.py`, `tools/chemenu/tests/binary_formats.py`,
+   `tools/requirements.txt` or `.gitea/workflows/converters.yml` - the `Converters` workflow
+   (`converters.yml`) starts by itself beside CI and derives the real documents of the private
+   test corpus. It takes longer than CI (allow **10 minutes**); wait for it the same way, with
+   the same give-up time, and count a red run like a red CI run (step 4). Start it by hand
+   (`actions_run_write`, `dispatch_workflow` on `main`) when only the private repository changed
+   or when the commit reaches the converters only indirectly. A release without suffix runs the
+   same steps as the first job of `release.yml`, which the release waits for.
+
 4. **A red run is not waited past.** Read the failing job's log, fix the cause, and go back to
    step 1: this is still build work, whichever skill published. The phase that published ends
    only on a green run, and the issue stays open until there is one.