fix: apt deb822/OpenSSL3/pbzx-repo build errors + Big-Sur+-Katalogfilter

- Dockerfile: hfsprogs-Sources per sed auf bestehende deb822-Datei
  patchen statt zweite sources.list-Datei (Signed-By-Konflikt)
- Dockerfile: xar configure.ac OpenSSL-Probe auf EVP_EncryptInit
  umbiegen (OpenSSL_add_all_ciphers ist in OpenSSL 3.x nur noch Makro)
- Dockerfile: xar vor pbzx bauen (Linker-Abhaengigkeit), pbzx-Quelle auf
  NiklasRosenstein/pbzx (mackyle/pbzx existiert nicht mehr)
- catalog.py: doppeltes gzip.decompress auf bereits von requests
  dekomprimierten Content entfernt
- catalog.py: Big-Sur-bis-Tahoe-Installer wurden durch veralteten
  OSInstall-Filter komplett verworfen, jetzt SharedSupport-Schema
  ebenfalls erkannt (37 statt 13 gefundene Installer)

Alles live gegen echten docker compose build/up + echten Apple-Katalog
verifiziert, nicht nur behauptet.

README.md

@@ -69,13 +69,71 @@ Block-Device. Wenn du das falsche Geraet auswaehlst, sind die Daten weg.
 Vor dem Start immer pruefen, welcher Stick tatsaechlich gemeint ist (Groesse
 und Modell in der GUI vergleichen).
 
-## Build-Hinweis (hfsprogs / xar)
-`hfsprogs` liegt in Debians non-free-Bereich (Dockerfile aktiviert das
-gezielt ueber eine eigene sources.list.d-Datei), `xar` gibt es in
-`bookworm` ueberhaupt nicht als Paket — das wird deshalb aus dem
-Upstream-Repo (`mackyle/xar`, selber Maintainer wie das schon genutzte
-`pbzx`) selbst gebaut. Macht den ersten Build minimal langsamer, aber
-zuverlaessiger als ein Distro-Wechsel.
+## Build-Hinweis (hfsprogs / xar / pbzx)
+Alles unten wurde am 2026-07-18 live gegen einen echten `docker compose build`
++ `up` auf einem echten Docker-Host getestet (nicht nur behauptet):
+
+- `hfsprogs` liegt in Debians non-free-Bereich. WICHTIG: `bookworm-slim`
+  nutzt das neue **deb822**-Sourcen-Format (`/etc/apt/sources.list.d/
+  debian.sources` statt der alten `sources.list`). Eine zusaetzliche
+  separate `sources.list`-Datei fuer dieselbe `deb.debian.org`-URI OHNE
+  `Signed-By` fuehrt zu `Conflicting values set for option Signed-By` und
+  bricht `apt-get update` komplett ab. Der Dockerfile patcht deshalb die
+  bestehende `debian.sources` per `sed` (Components-Zeile um
+  `contrib non-free non-free-firmware` erweitert) statt eine zweite Quelle
+  anzulegen.
+- `xar` gibt es in `bookworm` ueberhaupt nicht als Paket, wird aus dem
+  Upstream-Repo `mackyle/xar` gebaut. Dessen `configure.ac` prueft
+  OpenSSL ueber `AC_CHECK_LIB([crypto], [OpenSSL_add_all_ciphers])` --
+  diese Funktion ist in OpenSSL 3.x (Debian bookworm) nur noch ein
+  no-op-Praeprozessor-Makro in `evp.h`, kein linkbares Symbol mehr. Der
+  Autoconf-Test schlaegt deshalb fehl ("Cannot build without libcrypto"),
+  obwohl `libssl-dev` korrekt installiert ist. Fix: der Dockerfile biegt
+  den Probe-Funktionsnamen per `sed` auf `EVP_EncryptInit` um (gegen
+  `libcrypto.so.3` per `nm` verifiziert, seit jeher stabil exportiert).
+- `xar` MUSS vor `pbzx` gebaut werden -- `pbzx` linkt gegen `-lxar` und
+  `xar/xar.h`.
+- `pbzx`: das Repo `mackyle/pbzx` existiert nicht (mehr) auf GitHub (404).
+  Git meldet das irrefuehrend als `could not read Username for
+  'https://github.com'`, weil GitHub bei `git-upload-pack`-Requests gegen
+  nichtexistente/private Repos aus Anti-Enumeration-Gruenden 401 statt 404
+  zurueckgibt. Fix: Community-Standard-Fork
+  [`NiklasRosenstein/pbzx`](https://github.com/NiklasRosenstein/pbzx)
+  (u.a. in OSX-KVM genutzt) wird stattdessen geklont.
+
+Macht den ersten Build minimal langsamer, aber zuverlaessiger als ein
+Distro-Wechsel.
+
+## Katalog-Bugs (gefunden + gefixt, 2026-07-18)
+Zwei echte Bugs in `backend/catalog.py`, beide live gegen den echten
+Apple-Katalog (`swscan.apple.com`) reproduziert und verifiziert:
+
+1. **Doppeltes Entpacken:** Apples Server schickt den Katalog mit
+   `Content-Encoding: x-gzip`. `requests`/`urllib3` dekomprimiert das
+   bereits TRANSPARENT -- der Code rief zusaetzlich `gzip.decompress()`
+   drauf auf, was mit `BadGzipFile: Not a gzipped file` crashte (die
+   Gzip-Magic-Bytes waren durch die automatische Dekompression laengst
+   weg). Fix: nur noch entpacken wenn die Bytes wirklich noch mit der
+   Gzip-Magic (`\x1f\x8b`) anfangen.
+2. **Big Sur+ wurde komplett ausgefiltert:** `_is_macos_installer()` prüfte
+   nur auf das klassische Schema
+   (`ExtendedMetaInfo.InstallAssistantPackageIdentifiers.OSInstall ==
+   "com.apple.mpkg.OSInstall"`, gueltig bis Catalina). Ab Big Sur nutzt
+   Apple stattdessen einen `SharedSupport`-Key
+   (`com.apple.pkg.InstallAssistant.macOSBigSur`, `...macOSTahoe`, etc.) --
+   ohne den alten Key. Der Filter hat dadurch STILLSCHWEIGEND alle
+   Big-Sur-bis-Tahoe-Installer verworfen, obwohl sie im selben Katalog
+   laengst enthalten waren (live verifiziert: 24 InstallAssistant.pkg-
+   Eintraege im Katalog, 0 davon trafen den alten Filter). Genau der
+   `recovery`-Pfad, den dieses Tool eigentlich anbieten soll. Fix:
+   `_is_macos_installer` erkennt jetzt beide Schemata; `_fetch_product_
+   metadata` faellt bei fehlendem `ServerMetadataURL` (Big Sur+ hat keins)
+   auf den Namen aus dem `SharedSupport`-Identifier zurueck. Nach dem Fix:
+   37 statt 13 Installer gefunden, inkl. macOS Tahoe.
+
+Beide Fixes wurden nicht nur im Code geaendert, sondern gegen den echten,
+frisch gebauten Container end-to-end verifiziert (`/api/versions` liefert
+jetzt tatsaechlich Big Sur bis Tahoe zurueck).
 
 ## Voraussetzungen auf dem Host
 - Docker + Docker Compose