fix(setup): Dateirechte bei Geheimnissen, plattformabhaengige Zielnamen

Zwei Beobachtungen aus der laufenden Integration.

1. Der Installer schrieb Geheimnisse weltlesbar
   SetupWriter benutzte File.WriteAllText ohne Rechteanpassung - unter Linux
   also die Standardmaske und damit ueblicherweise 644. In genau dieser Datei
   stehen Lizenzschluessel und Anwendungstoken; jeder Benutzer des Systems
   konnte sie lesen. Der Lizenz-Cache in StateStore wird aus demselben Grund
   seit jeher auf 600 gesetzt - der Installer zog nicht nach.
   Enthaelt ein Ziel mindestens einen geheimen Wert, wird die Datei jetzt auf
   den eigenen Benutzer beschraenkt. Als geheim gilt type=secret UND
   source=provision: ein so geholtes Token traegt oft den Typ "string", ist
   aber genauso schutzbeduerftig. Unter Windows bleibt es beim Profil-ACL.

2. Zielnamen koennen plattformabhaengig unterschiedlich sein
   %APPDATA%\MeineAnwendung gegen $XDG_CONFIG_HOME/meineanwendung - eine
   setup.json kannte nur eine Schreibweise. Die kleingeschriebene Form allein
   traegt, weil NTFS die Schreibweise ignoriert, aber nur solange das
   Dateisystem tatsaechlich unempfindlich ist; auf APFS mit Beachtung der
   Schreibweise oder bei groesseren Unterschieden entstuende ein zweites,
   leeres Verzeichnis neben dem, aus dem die Anwendung liest.
   Ziele haben deshalb optional fileWindows, fileLinux und fileMacOS; ohne
   Angabe gilt weiterhin file.

Die Dokumentation haelt ausserdem fest, dass der Installer bewusst Klartext
schreibt und die Anwendung selbst entscheidet, ob und wie sie ihn danach
schuetzt - und dass eine Entschluesselung, die Klartext durchreicht, deshalb
kein Altlast-Zweig mehr ist, sondern ein aktiv genutzter Pfad.

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

client-dotnet/Deploymentcenter.Client/Models/SetupDefinition.cs

@@ -51,6 +51,34 @@ namespace Deploymentcenter.Client.Models
         [JsonPropertyName("file")]
         public string File { get; set; } = string.Empty;
 
+        /// <summary>
+        /// Abweichender Pfad unter Windows.
+        ///
+        /// Konfigurationsordner heissen plattformabhaengig unterschiedlich:
+        /// unter Windows ist "%APPDATA%\MeineAnwendung" ueblich, unter Linux
+        /// "$XDG_CONFIG_HOME/meineanwendung" klein. Meist genuegt es, die
+        /// kleingeschriebene Form anzugeben - NTFS unterscheidet nicht nach
+        /// Gross- und Kleinschreibung, umgekehrt entstuende unter Linux ein
+        /// zweites, leeres Verzeichnis neben dem, aus dem die Anwendung liest.
+        ///
+        /// Das traegt aber nur, solange das Dateisystem tatsaechlich
+        /// unempfindlich ist - auf APFS mit Beachtung der Schreibweise oder
+        /// einem per fsutil umgestellten NTFS-Ordner nicht mehr. Und es hilft
+        /// gar nicht, wenn sich die Namen um mehr als die Schreibweise
+        /// unterscheiden. Fuer diese Faelle sind die folgenden Felder da; ohne
+        /// Angabe gilt <see cref="File"/>.
+        /// </summary>
+        [JsonPropertyName("fileWindows")]
+        public string FileWindows { get; set; } = string.Empty;
+
+        /// <summary>Abweichender Pfad unter Linux.</summary>
+        [JsonPropertyName("fileLinux")]
+        public string FileLinux { get; set; } = string.Empty;
+
+        /// <summary>Abweichender Pfad unter macOS.</summary>
+        [JsonPropertyName("fileMacOS")]
+        public string FileMacOS { get; set; } = string.Empty;
+
         /// <summary>
         /// Wo die Datei liegt:
         ///