CI fuer Gitea Actions: Build und Tests auf Linux plus Waechter gegen Rueckfaelle

Die Plattformneutralitaet war nach dem WinForms-Ausbau eine Momentaufnahme: eine
einzige net10.0-windows-Zeile oder ein "using System.Drawing" genuegt, und der
Linux-Build ist kaputt, ohne dass es auf einer Windows-Maschine auffaellt - dort
baut es weiter. Genau das faengt die CI ab, und zwar auf Linux.

.gitea/workflows/ci.yml, zwei Jobs auf ubuntu-latest:

- build-test: restore, build, die 476 Tests (brauchen keine DB, laufen gegen
  EF-InMemory), Linux-Publish. Der Publish ist kein Selbstzweck - dort faellt
  auf, wenn ein Paket doch windows-only ist. Anschliessend wird geprueft, dass
  die Executable, appsettings.json, setup.json und libSkiaSharp.so wirklich im
  Ergebnis liegen.
- guard: keine windows-TFMs, kein UseWindowsForms/UseWPF, keine windows-only
  using-Direktiven, keine versionierten Secret-Dateien, keine anfaelligen Pakete.

Alle Waechter sind in beide Richtungen gegengeprueft: sie schlagen bei
simulierten Regressionen an (windows-TFM, UseWindowsForms, using System.Drawing,
getrackte packager.config.json samt dc_sub_-Token, Newtonsoft 11.0.2) und
schweigen beim Ist-Zustand. Die Namespace-Pruefung trifft bewusst nur echte
using-Direktiven: im Bestand steht an vielen Stellen erklaert, WARUM
System.Drawing nicht verwendet wird, und das darf keinen Fehlalarm ausloesen.

Der Schwachstellen-Check ist Punkt 1 der wiederkehrenden Audit-Checkliste aus
dem Sicherheitskonzept - laeuft ab jetzt bei jedem Push statt quartalsweise von
Hand. Er wuerde zum Beispiel anschlagen, wenn der Newtonsoft-Pin im Core faellt.

Bewusst kein -warnaserror: die 15 vorhandenen Warnungen muessten erst weg, sonst
ist die CI ab dem ersten Tag rot und wird ignoriert.

WICHTIG - die CI laeuft noch nicht: auf der Gitea-Instanz ist kein Actions-Runner
registriert (auf Repo-, Benutzer- und Instanzebene geprueft, ueberall 0).
has_actions ist true, es fehlt nur der Runner. Einrichtung Schritt fuer Schritt
in docs/LEITFADEN-CI.md Abschnitt 3.

.gitattributes neu: erzwingt LF fuer .yml/.sh/.service. Entwickelt wird mit
autocrlf=true auf Windows, ausgefuehrt auf Linux - ein Shell-Skript mit CRLF
scheitert dort mit irrefuehrenden Meldungen. Bisher gab es keine .gitattributes.

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

docs/PROJEKTSTAND.md

@@ -114,7 +114,7 @@ etwas anderes:
 
 | Punkt | Details |
 |---|---|
-| **Keine CI** | Weder `.github/workflows` noch `.gitea/workflows` — es existiert keinerlei Automatisierung. Build und Tests laufen ausschließlich von Hand. **Der größte strukturelle Mangel** |
+| **CI: Workflow da, Runner fehlt** | [`.gitea/workflows/ci.yml`](../.gitea/workflows/ci.yml) ist angelegt (Build + 476 Tests + Linux-Publish auf Linux, dazu Wächter gegen windows-spezifische Rückfälle, versionierte Secrets und anfällige Pakete). **Auf der Gitea-Instanz ist aber kein Runner registriert** — geprüft auf Repo-, Benutzer- und Instanzebene. Bis der Runner steht, läuft der Workflow nicht. Einrichtung: [LEITFADEN-CI.md](./LEITFADEN-CI.md) §3 |
 | **15 Build-Warnungen** | Alle im Avalonia-Projekt: 13 × `CS8618` (Felder in Fenster-Konstruktoren), 1 × `CS8848` (Vorrang bei `switch`), 1 × `CS8602` (möglicher Nullverweis in `PdfExporter.cs:40`). Die letzten beiden sind einen Blick wert |
 | **TerminalLogger** | Stempelt mit `DateTime.Now` statt der konfigurierten `AppTimeZone`. Auf einem UTC-Linuxserver passen Logdatei-Grenzen nicht zur angezeigten Uhrzeit. Umstellung auf `Microsoft.Extensions.Logging` steht ohnehin aus |
 | **God-Methoden** | `PollLiveAccountsAsync`, `ProcessAccountOrderAsync`; duplizierte Closed-Trade-Erzeugung (Phase 7) |
@@ -173,6 +173,7 @@ gekennzeichnet, `ANALYSE-Linux-Portierung.md` steht auf Revision 6.
 | `PROJEKTSTAND.md` | **Dieses Dokument** — Einstieg und Gesamtüberblick |
 | `ANALYSE-Linux-Portierung.md` | Rahmen der Linux-Fähigkeit, Fahrplan P1–P11 / L1–L5 |
 | `LEITFADEN-Avalonia-Portierung.md` | Arbeitsregeln für die Oberfläche. **Vor jeder UI-Arbeit lesen** |
+| `LEITFADEN-CI.md` | Was die CI prüft und wie der Gitea-Runner eingerichtet wird |
 | `UI-SPEZIFIKATION-WinForms.md` | Beschreibung der alten Oberfläche — Vergleichsvorlage für A5 |
 | `umsetzungsplaene/` | Detailpläne je Vorhaben |
 | `konzepte/` | Vorhaben ohne Umsetzungsplan |
@@ -188,8 +189,9 @@ gekennzeichnet, `ANALYSE-Linux-Portierung.md` steht auf Revision 6.
 
 1. **A5 durchklicken** — die Oberfläche mit echten Daten abnehmen. Blockiert nichts
    technisch, ist aber die letzte offene Zusage der UI-Portierung.
-2. **CI aufsetzen** — der größte strukturelle Mangel. Ein Workflow, der `dotnet build` und
-   `dotnet test` auf Linux fährt, hätte den plattformneutralen Zustand von allein gehalten.
+2. **CI scharf schalten** — der Workflow liegt, es fehlt nur der Runner (etwa 10 Minuten,
+   siehe [LEITFADEN-CI.md](./LEITFADEN-CI.md) §3). Erst dann hält der plattformneutrale
+   Zustand von allein; bis dahin ist er nur eine Momentaufnahme.
 3. **Deploymentcenter live abnehmen** — danach können die Altdienste abgeschaltet werden,
    womit zwei Sicherheits-Auflagen von selbst entfallen.
 4. **Erst dann neue Module.** MarketMaking und BundleArbitrage sind fertig geplant und