fix(releases): Lizenzschluessel nicht mehr im Klartext, Selbsttest, Zielorte

Vier Befunde aus einer externen Durchsicht der 2.4-Integration.

1. Die .htpasswd war eine Klartext-Kundenliste
   Das htpasswd-Format hasht nur die Passwortspalte. Benutzername UND Passwort
   waren der Lizenzschluessel - der Schluessel stand also im Klartext direkt
   neben seinem eigenen bcrypt-Hash, und der Hash war Dekoration. Geschuetzt
   hat das Ganze nur die FilesMatch-Regel in derselben Datei.
   Der Benutzername wird jetzt abgeleitet: lic_<sha256(schluessel), 16 Hex>.
   Die Datei enthaelt damit nur noch eine Einwegableitung und einen Hash ueber
   einen hochentropen Schluessel.
   Server und SDK muessen dabei zeichengenau uebereinstimmen; ein Test prueft
   die C#-Ableitung gegen die PHP-Formel.

2. Ein Formatwechsel blieb unbemerkt liegen
   Beim Umbau auf 1. faellt auf: reconcile() sah keinen Anlass zur
   Neuerzeugung, die Dateien behielten das alte Format, waehrend die Clients
   bereits das neue schickten. Die erzeugten Dateien tragen deshalb jetzt eine
   Formatkennung; weicht sie ab, wird neu erzeugt.

3. Doku beschrieb Nginx, der Schutz ist Apache-only
   .htaccess wird von Nginx ignoriert - dort waeren die Verzeichnisse offen und
   die .htpasswd oeffentlich abrufbar. Die Statusanzeige pruefte nur, ob die
   Dateien existieren, und haette in dem Fall "GESCHUETZT" gemeldet.
   Neu: ein echter Selbsttest ruft die eigene Paket-Adresse OHNE Zugangsdaten
   ab und erwartet 401. Er laeuft beim manuellen Erzeugen und nach jeder
   automatischen Neuerzeugung; das Ergebnis steht in der Oberflaeche, ein
   Fehlschlag im Log. Er findet nebenbei auch abgeschaltetes AllowOverride und
   Tippfehler in der erzeugten Datei. Doku korrigiert, Nginx-Vorlage ergaenzt.

4. Erstinstallation schrieb an einen Ort, an dem Linux-Anwendungen nicht lesen
   setup.json-Ziele waren immer installationsrelativ. Eine Anwendung, die sich
   unter Linux richtig verhaelt, liest aus $XDG_CONFIG_HOME - /opt/<app> ist
   fuer den Dienstbenutzer meist nicht schreibbar. Der Installer legte die
   Datei also dorthin, wo nie jemand nachsieht.
   Ziele haben jetzt ein "location": install (Vorgabe), config, data, home,
   plus ${VAR}- und %VAR%-Ersetzung in "file". Unbekannte Variablen bleiben
   stehen statt leer zu werden - ein Platzhalter faellt auf, ein falscher Pfad
   nicht. Der Installer gibt den aufgeloesten Pfad aus, weil bei config das
   Konto entscheidet, unter dem er laeuft.

Ausserdem
- Doku zeigte "status": "ok" fuer update/delete; Http::ok() erzeugt
  "status": "success".
- UPGRADE §16.1 deckte Neuprodukte nicht ab: Fuer ein Produkt ohne Release
  existiert /releases/<slug>/ nicht und wird uebersprungen. Das Verzeichnis
  entsteht erst mit dem ersten Upload, der naechste Tick schuetzt es. Der erste
  ausgelieferte Build muss die Zugangsdaten also schon mitbringen.

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

docs/SETUP_INTEGRATION_GUIDE.md

@@ -182,6 +182,43 @@ entpackt sie dann nur und fragt nichts ab.
 | `validate` | Regulärer Ausdruck |
 | `target` | `id` des Ziels, wenn es mehrere gibt |
 
+### Wohin geschrieben wird
+
+Ein Ziel hat neben `file` eine Ortsangabe:
+
+```json
+"targets": [
+  { "id": "app",  "file": "appsettings.json",             "format": "json" },
+  { "id": "user", "file": "clawddotnet/Settings.json",
+    "location": "config", "format": "json" }
+]
+```
+
+| `location` | Windows | Linux / macOS |
+|---|---|---|
+| `install` (Vorgabe) | Installationsverzeichnis | Installationsverzeichnis |
+| `config` | `%APPDATA%` | `$XDG_CONFIG_HOME`, sonst `~/.config` |
+| `data` | `%LOCALAPPDATA%` | `$XDG_DATA_HOME`, sonst `~/.local/share` |
+| `home` | Benutzerprofil | `$HOME` |
+
+**Warum das nötig ist:** Eine Anwendung, die sich unter Linux richtig verhält,
+legt ihre Konfiguration nicht neben das Programm — `/opt/<app>` ist für den
+Dienstbenutzer typischerweise nicht schreibbar. Ohne Ortsangabe schriebe der
+Installer die Datei dorthin, wo die Anwendung nie nachsieht.
+
+In `file` sind Umgebungsvariablen in beiden Schreibweisen erlaubt:
+`${XDG_CONFIG_HOME}/app/Settings.json` und `%APPDATA%\app\Settings.json`. Ein
+absoluter Pfad wird unverändert benutzt. Unbekannte Variablen bleiben stehen,
+statt zu einer leeren Zeichenkette zu werden — ein stehengebliebener
+Platzhalter fällt auf, ein stillschweigend falscher Pfad nicht.
+
+> **Wer den Installer startet, entscheidet mit.** `config`, `data` und `home`
+> beziehen sich auf das Konto, unter dem der Installer läuft. Wird er als
+> `root` oder Administrator gestartet, der Dienst aber unter einem eigenen
+> Konto betrieben, landet die Datei im falschen Profil. Der Installer gibt
+> deshalb den **aufgelösten Pfad** aus — prüfe ihn. Für Dienste ist ein
+> absoluter Pfad oft die ehrlichere Angabe.
+
 `type` bestimmt auch, **wie** geschrieben wird: `int` und `bool` landen als
 JSON-Zahl beziehungsweise -Wahrheitswert, nicht als Zeichenkette. Sonst
 scheitert die Bindung in der Anwendung.