Verstaendlicher Abbruch statt Absturz, wenn die Datenbankverbindung fehlt

Erster Befund aus dem Linux-Lauf auf der Test-VM (Roadmap A4a): Ohne
konfigurierte Datenbank startete die Anwendung los und starb erst tief im
DI-Aufbau mit einer unbehandelten ArgumentException und rund 50 Zeilen
Stacktrace - "The string argument 'connectionString' cannot be empty", geworfen
aus dem EF-Kern. Exitcode 134 (SIGABRT).

Fuer den Serverbetrieb ist das gleich doppelt schlecht: Der Betreiber sieht
nicht, was fehlt, und systemd startet den Dienst wegen Restart=on-failure alle
zehn Sekunden neu. Im Journal stehen dann endlose Startversuche statt der
Ursache. Genau dieser Zustand ist bei einer Erstinstallation der wahrscheinlichste
- Software liegt da, Zugangsdaten sind noch nicht gesetzt.

Behoben an drei Stellen:
- Program.Main prueft die Verbindung, bevor der Host gebaut wird, und gibt aus,
  welcher Schluessel in welcher Datei erwartet wird, samt Beispiel und dem
  Hinweis, dass das Schema per "dotnet ef database update" angelegt wird (die
  Anwendung migriert nicht selbst).
- Rueckgabewert 78 (EX_CONFIG aus den BSD-sysexits) statt eines Absturzes.
- deploy/polytrader.service traegt RestartPreventExitStatus=78 - ein
  Konfigurationsfehler repariert sich durch Neustarts nicht, er wird dadurch nur
  unsichtbar.
- AddCorePersistence wirft als zweite Verteidigungslinie eine
  InvalidOperationException mit derselben Aussage, falls jemand die Methode
  direkt aufruft.

Der Connection-String wird dabei ueber dieselben Dateien und denselben Schluessel
gelesen wie spaeter im Host, damit beide Wege nicht auseinanderlaufen koennen.

Build gruen, 476 Tests gruen (Windows und Linux).

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

src/PolyTrader.Core/DependencyInjection/ServiceCollectionExtensions.cs

@@ -1,4 +1,4 @@
-using System;
+using System;
 using Microsoft.EntityFrameworkCore;
 using Microsoft.Extensions.DependencyInjection;
 using PolyTrader.Core.Configuration;
@@ -17,6 +17,18 @@ namespace PolyTrader.Core.DependencyInjection
         public static IServiceCollection AddCorePersistence(this IServiceCollection services, DatabaseOptions options)
         {
             var conn = options.MySqlConnectionString;
+
+            // Zweite Verteidigungslinie. Der Regelfall wird frueh in Program.Main abgefangen
+            // (verstaendliche Meldung + Exit 78); wer diese Methode direkt aufruft, bekam bisher
+            // erst tief im DI-Aufbau eine ArgumentException aus dem EF-Kern, der man den
+            // eigentlichen Grund nicht ansieht.
+            if (string.IsNullOrWhiteSpace(conn))
+            {
+                throw new InvalidOperationException(
+                    "Kein MySQL-Connection-String konfiguriert. Erwartet wird " +
+                    "'Database:MySqlConnectionString' in appsettings.Local.json neben der Programmdatei.");
+            }
+
             services.AddDbContextFactory<CoreDbContext>(o => o.UseMySql(conn, DatabaseServerVersion.Value));
 
             services.AddSingleton<IAccountRepository, EfAccountRepository>();