fix(xrechnung): bound validator output and report reads

Enforce capture limits while draining both subprocess pipes, kill and reap interrupted validators, and bound report allocation before parsing. Preserve result precedence and add synthetic-process regressions with EN/DE documentation.

Refs #2

docs/INBOUND_VALIDATION.md

@@ -31,6 +31,51 @@ The configuration tree must be installed through deployment governance. A newer
 
 Inbound XML is size-bounded and parsed with external entities and DTD processing disabled before Java runs. KoSIT runs without a shell, with an absolute executable, fixed argument vector, bounded time, bounded captured output, and an isolated result directory.
 
+The validator's stdout and stderr share a fixed 2 MiB capture limit, including
+the single separator byte used when inspecting their combined output. Both
+streams are drained while the validator runs. If the next byte exceeds that
+limit, GovOPlaN kills and reaps the direct validator process and returns
+`failed` with the reason `KoSIT runner output exceeded the safety limit.`
+Conformance and assessment remain `unknown`, and no handoff is allowed even
+if a valid-looking report was already written. The existing timeout (120 seconds
+by default, configurable from 1 to 600 seconds) also kills and reaps the
+validator; cancellation propagates after the same cleanup. Output is not
+included in these technical-failure reasons. Operators should check the
+approved engine and configuration using synthetic inputs before retrying an
+output-limit failure. The pipe runner uses POSIX process facilities; deployment
+resource limits and descendant-process isolation remain outside this capture
+bound.
+
+Report reads are bounded to the existing 16 MiB limit plus one probe byte.
+Reports exactly at the limit remain eligible for normal interpretation;
+oversized reports cannot supply trusted evidence and yield `incomplete` with
+unknown conformance unless an earlier runner failure already determines the
+outcome. An output-limit failure skips reading the report entirely. This read
+bound does not limit how much report data the validator can write to disk.
+
+Standardausgabe und Standardfehlerausgabe des Validators teilen eine feste
+Erfassungsgrenze von 2 MiB einschließlich eines Trennbytes. Beide Ausgaben
+werden während des Laufs gelesen. Bei Überschreitung beendet GovOPlaN den
+direkten Validatorprozess und wartet dessen Abschluss ab. Das Ergebnis lautet
+`failed` mit unbekannter Konformität und Bewertung (`unknown`); auch ein
+scheinbar gültiger Bericht erlaubt keine Übergabe. Das bestehende Zeitlimit
+(standardmäßig 120 Sekunden, konfigurierbar von 1 bis 600 Sekunden) beendet den
+Prozess ebenfalls; ein Abbruch wird nach der Prozessbereinigung weitergegeben.
+Diese technischen Fehlergründe enthalten keine Runner-Ausgabe. Betreibende
+sollten das freigegebene Profil vor einem erneuten Versuch mit synthetischen
+Eingaben prüfen. Der Pipe-Runner verwendet POSIX-Prozessfunktionen;
+Ressourcengrenzen der Installation und die Isolation von Kindprozessen bleiben
+außerhalb dieser Erfassungsgrenze.
+
+Berichte werden höchstens bis zur bestehenden Grenze von 16 MiB zuzüglich
+eines Prüfbytes gelesen. Berichte genau an der Grenze werden normal
+ausgewertet; übergroße Berichte liefern keinen vertrauenswürdigen Nachweis und
+ergeben `incomplete` mit unbekannter Konformität, sofern nicht bereits ein
+vorrangiger Runner-Fehler das Ergebnis bestimmt. Bei Überschreitung der
+Runner-Ausgabegrenze wird der Bericht gar nicht gelesen. Die Lesegrenze
+begrenzt nicht die Berichtsmenge, die der Validator auf Datenträger schreiben
+kann.
+
 GovOPlaN does not trust the report alone. A technically complete result requires a zero process status, no technical error marker in runner output, a bounded well-formed VARL report, a matched scenario, at least the configured number of complete validation steps, and exactly one assessment. Formal validity and the accept/reject recommendation are retained separately because warnings can make them differ. This compensates for the known risk that a partial report can look valid after a transformation failure.
 
 Semantic invalidity is different from technical failure. A complete reject report is `invalid`; a timeout, crash, partial report, or inconsistent assessment is `unknown`. Neither result may be handed off as valid.