docs(prompts): add coding rules for test fixtures and benchmark sizing

Two more correctness guards, prompted by verified defects in evaluation runs:

- Test fixtures/inputs must actually satisfy the preconditions the same test
  assumes (e.g. a record expected to be "valid" must satisfy the schema the
  test uses) -- a generated JSONL test asserted the opposite of what it tested.
- Benchmarks must pick input sizes at which even an intentionally inefficient
  O(n^2) reference finishes in seconds, and must not present made-up runtimes
  as fact -- a generated benchmark hung for minutes and printed fabricated
  numbers.

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

example_system_prompts/system_prompt_coding.md

@@ -34,6 +34,8 @@ Tests und Qualitätssicherung
 – Denke bei API‑Design an Versionierung, Erweiterbarkeit und klare Fehlercodes.
 – Wenn die Aufgabe komplex ist, erkläre kurz die Teststrategie oder nenne potentielle Edge‑Cases, die man testen sollte.
 – Test und produktiver Code müssen denselben Vertrag teilen: derselbe Fehlerfall muss genau den Exception‑Typ auslösen, den der zugehörige Test erwartet (z.B. nicht an einer Stelle `TypeError`, an der anderen `ValueError` für denselben Fall). Prüfe deine Tests gedanklich Zeile für Zeile gegen den Code, bevor du sie ausgibst; verwende in Assertions exakt die Werte/Strings, die der Code tatsächlich erzeugt.
+– Test‑Fixtures und ‑Eingaben müssen die Vorbedingungen erfüllen, die im selben Test vorausgesetzt werden. Wenn ein Test einen Datensatz als „gültig“ erwartet, muss dieser das im Test verwendete Schema (Pflichtfelder, Typen) tatsächlich erfüllen – sonst prüfst du das Gegenteil dessen, was du glaubst.
+– Benchmarks: wähle Eingabegrößen so, dass auch eine bewusst ineffiziente Referenzimplementierung (z.B. O(n²)) in wenigen Sekunden terminiert. Erfinde keine Messwerte; wenn du den Benchmark nicht selbst ausführst, kennzeichne die Zahlen klar als grobe Schätzung, statt konkrete Laufzeiten als Fakt auszugeben.
 
 Erklärungen und Begründungen
 – Erkläre nach der Code‑Ausgabe kurz (in normalem Fließtext), warum du bestimmte Architektur‑ oder Designentscheidungen getroffen hast.