dns-naming: reverse zone was actually broken, not just stale docs - fixed live

Live audit found 4 records in the reverse zone, all wrong: 2 malformed
PTR entries (name/value swapped, never actually resolved), 1 orphaned
record from a decommissioned host, 1 correct-looking but misleading
record (proxy host's PTR pointing at one proxied app's name instead of
its own identity). All fixed live on Technitium today, not just
documented. Doc updated to describe the real defect and the fix.

docs/dns-naming.md

@@ -50,7 +50,7 @@ Same result for `loki` and `wazuh-indexer` (caddy-zone only), and the reverse fo
 
 Trusting the KB without re-checking it against the running server would have kept both of these wrong indefinitely — so both got checked directly against the real config and the real zone data, not taken on the KB's word:
 
-- **A reverse zone that wasn't scoped the way it was documented.** It was described as covering just the observability host's own subnet slice. The zone's own name on the real server settles that on its own — it's the reverse zone for the entire `/24`, not a narrower delegation, which only a different naming pattern could express. Reverse-lookups spot-checked across 7 IPs in that range came back with only 2 real PTR records — and the observability host's own IP wasn't one of them, despite the zone supposedly being scoped around it. That's stale leftovers from an earlier setup, not a deliberate monitoring-scoped zone, and the documentation had simply never been re-checked against what the server was actually doing.
+- **A reverse zone that had real broken records, not just outdated documentation.** It was described as covering just the observability host's own subnet slice. The zone's own name on the real server settles that on its own — it's the reverse zone for the entire `/24`, not a narrower delegation, which only a different naming pattern could express. A full sweep of every address in the zone — not a sample — turned up four records, and none of them held up: two were malformed PTR entries with their name and value fields reversed, structurally incapable of ever answering a real reverse lookup, not just stale; one was an orphaned leftover from a host decommissioned months earlier; and the fourth — the internal reverse-proxy host's own reverse record — resolved to the name of one specific app proxied through it instead of the host's own identity. The observability host's own IP had no record at all, despite the zone supposedly being scoped around it. All three broken entries got removed and the fourth got corrected, rather than just written up as a known gap.
 - **A forwarder that was documented but never actually configured.** Technitium's upstream forwarding was written up as including a well-known public DNS-over-HTTPS provider. Reading the real config directly shows exactly two forwarders: the edge firewall and one other public resolver — the documented provider's IP and name appear nowhere in the file. It looks like it was documented as a plan and never actually implemented, then never revisited to catch the mismatch.
 
 ```