dns-naming: genericize the zone domains I missed in the evidence block

The rest of the doc consistently says 'browser-facing zone'/'app-to-app
zone' and never states the literal domain suffixes. One evidence code
block leaked both real domains as part of the FQDNs being resolved -
fixed to match the doc's own established pattern. Caught because I'd
only sanitize-checked my own diff, not the whole file - full-file grep
for thesabear.net now confirms zero literal domain mentions.

docs/dns-naming.md

@@ -30,9 +30,9 @@ A homelab this size could get away with a shared hosts file or a single flat zon
 Most apps that need both human and machine access get **one hostname per zone** — same app, two different front doors, chosen by which zone the caller resolves it in. Not every app needs both: a purely internal API integration might only ever get the app-to-app hostname; an app nobody automates against might only get the browser-facing one. The two zones aren't kept in lockstep by policy — a periodic audit is what actually catches when they drift, not an assumption that they match. As of the last audit, the app-to-app zone actually runs slightly ahead — 58 records versus 56 — with three apps present only there and one present only on the browser-facing side, real drift a policy alone wouldn't have caught:
 
 ```
-$ python3 -c "import socket; print(socket.gethostbyname('joplin.caddy.thesabear.net'))"
+$ python3 -c "import socket; print(socket.gethostbyname('joplin.[app-to-app zone]'))"
 [rocky-docker's IP]
-$ python3 -c "import socket; print(socket.gethostbyname('joplin.local.thesabear.net'))"
+$ python3 -c "import socket; print(socket.gethostbyname('joplin.[browser-facing zone]'))"
 socket.gaierror: [Errno -2] Name or service not known
 ```