docs(issues): #0027 W1 measured — no divergence, and correct my overstatement

Queried the lab resolver directly from inside the lab VLAN and compared every
record type against the public view: A, MX, TXT, CNAME, subdomains that exist
only publicly, plus records created and deleted yesterday. Not a single
divergence — the UDM holds no zone of its own and forwards live; the aa flag it
sets is a UniFi quirk and was what made the hypothesis look plausible.

That disproves the risk I asserted earlier in this issue, where I called the
pinned ACME resolvers 'load-bearing'. They are good practice, not a safety net
against W1, and the claim stood as fact for an hour. Corrected in place.

W1 is therefore documentation-only. What remains is that the purpose of the three
extra zones is recorded nowhere, which is why a blind rollback is the worse option.

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

docs/issues/0027-audit-01-acht-widersprueche-aus-dem-labnet-02.md

@@ -158,11 +158,16 @@ autoritativ (im Lab wurde genau das beobachtet: lokale Antworten mit gesetztem `
 sähe Traefik den frisch gesetzten TXT **nie** — die Erneuerung liefe in den Timeout, und zwar
 **still**, bis die Zertifikate ablaufen.
 
-Das passiert aktuell **nicht**, weil die Konfiguration die Prüf-Resolver explizit festnagelt:
-`--certificatesresolvers.letsencrypt.acme.dnschallenge.resolvers=1.1.1.1:53,8.8.8.8:53`
-(`thread-net-git`, Commit `8d089e2`). Diese Zeile ist damit **tragend**, nicht kosmetisch —
-sie umgeht genau die Zone aus W1. Wer sie beim nächsten Aufräumen für überflüssig hält,
-bricht die Zertifikatserneuerung, ohne es zu merken.
+Die Konfiguration nagelt die Prüf-Resolver ohnehin fest
+(`--certificatesresolvers.letsencrypt.acme.dnschallenge.resolvers=1.1.1.1:53,8.8.8.8:53`,
+`thread-net-git` `8d089e2`), womit die Frage für den ACME-Pfad praktisch nicht auftritt.
+
+⚠️ **Korrektur (gleicher Tag, nach der Messung unten):** Ich hatte diese Zeile hier zunächst
+als **tragend** bezeichnet — also behauptet, ohne sie bräche die Zertifikatserneuerung. Das
+war **überzogen**: die Messung zeigt, dass der Lab-Resolver die Zone live nach oben
+weiterreicht und den TXT damit sehr wahrscheinlich sähe. Die Festnagelung bleibt gute Praxis
+(deterministisch, umgeht Negativ-Caching), ist aber **kein Sicherheitsnetz gegen W1**. Die
+Hypothese war plausibel und ist widerlegt — sie stand hier eine Stunde lang als Tatsache.
 
 **Was weiterhin ungeprüft ist:** was die UDM für `axion1337.de` tatsächlich zurückgibt.
 Prüfbefehle (auf CFGMON):
@@ -183,3 +188,34 @@ Zonen, mit Begründung warum `~axion1337.de` überhaupt ins Lab zeigt) **oder**
 `~lab`. Für den Rückbau spricht, dass der Zweck der übrigen drei Zonen nirgends festgehalten
 ist; für das Nachführen spricht, dass sie auf sorbs Ansage entstanden sind — es gab also einen
 Grund, er steht nur nicht im ADR.
+
+### W1 — gemessen 2026-08-15: keine Abweichung, reines Doku-Problem
+
+Der Lab-Resolver wurde direkt abgefragt (vom Mac aus dem Lab-VLAN `10.58.73.26`, UDM
+`10.58.73.1:53` erreichbar) und Record für Record gegen die öffentliche Sicht (DoH) gestellt:
+
+| Abfrage | UDM | öffentlich |
+|---|---|---|
+| `rohana` A | `188.245.193.243` | identisch |
+| `selendis` A | `188.245.193.243` | identisch |
+| `axion1337.de` MX / TXT (SPF) | `10 mx00/mx01.ionos.de` / `v=spf1 …~all` | identisch |
+| `_dmarc` TXT, `s1-ionos._domainkey` CNAME | vorhanden | identisch |
+| `status`, `crypt` A (nur öffentlich existent) | korrekt | identisch |
+| **gestern angelegt:** `rohana` MX `0 .`, `_dmarc.rohana`, `rohana` SPF `-all` | **vorhanden** | identisch |
+| **gestern gelöscht:** `www.rohana`, `ftp` | **leer** | leer |
+
+**Ergebnis: keine einzige Abweichung** — auch nicht bei Records, die erst gestern entstanden
+bzw. gelöscht wurden. Die UDM hält **keine eigene Zone**, sondern reicht live nach oben durch;
+das gesetzte `aa`-Flag ist eine Eigenheit des UniFi-Resolvers und war der irreführende Teil,
+der die Hypothese überhaupt nahegelegt hat.
+
+**Damit ist die im Audit befürchtete Brisanz ausgeräumt:** Der Pfad zum Gitea-Mirror ändert
+sich nicht unbemerkt, weil der Lab-Resolver dieselben Daten liefert. **W1 ist ein reines
+Dokumentationsproblem**, kein Betriebsrisiko.
+
+**Was bleibt:** ADR-0004 beschreibt eine Zone, real sind es vier — und der **Zweck der drei
+Zusatzzonen ist nirgends festgehalten**. Das ist die eigentliche Lücke: Ohne diesen Grund kann
+niemand entscheiden, ob ein Rückbau auf `~lab` etwas kaputtmacht. Empfehlung daher:
+**ablösender ADR mit dem As-built-Stand** samt Begründung (sorb kennt sie), statt eines
+Rückbaus ins Blinde. Die Messung oben gehört als Beleg hinein — sie zeigt, dass die Zonen
+heute schadlos sind.