Testlauf, dem man glauben kann: Zeitzonen-Tests und Schluss mit Nebenlaeufigkeit

Zwei Tests zur Zeitzonen-Umstellung aus dem letzten Commit: der Zeitstempel
eines Logeintrags traegt den Versatz der ANZEIGE-Zone (nicht den des Systems),
und die abgelegte JSONL-Zeile traegt ihn mit. Sie liegen bewusst in
AppTimeZoneTests - dort steht der uebrige Zeitzonen-Zustand, und innerhalb einer
Klasse laufen Tests nacheinander.

Das genuegte aber nicht. Von sechs Laeufen fiel einer um und liess sich danach
nicht wieder einfangen. Die Ursache ist kein einzelner Test, sondern die Bauart:
Mehrere Bausteine halten prozessweiten Zustand, den Tests bewusst umstellen -
AppTimeZone, SecretProtection, die Diagnosezaehler von AccountIdSetJson. xUnit
fuehrt Testklassen standardmaessig nebenlaeufig aus, also sieht eine Klasse
mitten im eigenen Lauf, was eine andere gerade umgestellt hat.

Neu ist das nicht, aber die Zeitzonen-Umstellung hat es verschaerft: Seit die
Logzeitstempel der Anzeige-Zeitzone folgen, haengt jedes LogMessageEventArgs an
AppTimeZone - waehrend AppTimeZoneTests dieselbe Einstellung nach Auckland und
zurueck dreht.

Deshalb laufen die Testklassen jetzt nacheinander, und die Zaehlerpruefungen
arbeiten mit der Differenz statt mit absoluten Werten. Kosten: 4-5 s statt 3 s
Laufzeit. Ein Testlauf, dem man glauben kann, ist das allemal wert - danach
sechs Laeufe in Folge gruen.

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

tests/PolyTrader.Tests/AssemblyInfo.cs

@@ -0,0 +1,17 @@
+using Xunit;
+
+// Testklassen laufen NACHEINANDER, nicht parallel.
+//
+// Warum: Mehrere Bausteine der Anwendung halten prozessweiten Zustand, und die Tests stellen ihn
+// bewusst um — AppTimeZone (Anzeige-Zeitzone), SecretProtection (Master-Key) und die
+// Diagnosezähler von AccountIdSetJson. xUnit führt Testklassen standardmäßig nebenläufig aus;
+// dann sieht eine Klasse die Umstellung einer anderen mitten im eigenen Lauf.
+//
+// Das ist nicht theoretisch: Seit die Logzeitstempel der Anzeige-Zeitzone folgen (§8 des
+// Linux-Befundberichts vom 26.08.2026), hängt jedes LogMessageEventArgs an AppTimeZone — während
+// AppTimeZoneTests dieselbe Einstellung nach Auckland und zurück dreht. Am 28.08.2026 fiel dabei
+// ein Lauf von sechs um, ohne sich danach wieder einfangen zu lassen.
+//
+// Der Preis ist gering: Der gesamte Satz läuft in rund drei Sekunden. Ein Testlauf, dem man
+// glauben kann, ist das allemal wert.
+[assembly: CollectionBehavior(DisableTestParallelization = true)]