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/SetupPaths.cs

@@ -24,7 +24,7 @@ namespace Deploymentcenter.Client
         /// <param name="installDir">Installationsverzeichnis der Anwendung.</param>
         public static string Resolve(SetupTarget target, string installDir)
         {
-            string file = Expand(target?.File ?? string.Empty);
+            string file = Expand(FileFor(target));
 
             // Ein absoluter Pfad ist bereits die Antwort - etwa nachdem
             // ${XDG_CONFIG_HOME} ersetzt wurde.
@@ -37,6 +37,28 @@ namespace Deploymentcenter.Client
             return Path.GetFullPath(Path.Combine(root, file.Replace('/', Path.DirectorySeparatorChar)));
         }
 
+        /// <summary>
+        /// Waehlt den Pfad fuer die laufende Plattform.
+        ///
+        /// Konfigurationsordner heissen plattformabhaengig unterschiedlich -
+        /// "ClawdDotNet" unter Windows, "clawddotnet" unter Linux. Die
+        /// kleingeschriebene Form allein traegt nur, solange das Dateisystem
+        /// die Schreibweise ignoriert; auf einem case-sensitiven Volume
+        /// entstuende sonst ein zweites, leeres Verzeichnis neben dem, aus dem
+        /// die Anwendung liest.
+        /// </summary>
+        public static string FileFor(SetupTarget? target)
+        {
+            if (target == null)
+                return string.Empty;
+
+            string specific = OperatingSystemHelpers.IsWindows() ? target.FileWindows
+                            : OperatingSystemHelpers.IsMacOS()   ? target.FileMacOS
+                            : target.FileLinux;
+
+            return string.IsNullOrWhiteSpace(specific) ? (target.File ?? string.Empty) : specific;
+        }
+
         /// <summary>
         /// Wurzelverzeichnis fuer eine Ortsangabe.
         ///