docs: document opn-cli for managing the OPNsense site routers

Add a "Managing the OPNsense routers" note to generic.md §11 (Network):
opn-cli talks to a site's OPNsense over its API, credentials in a per-site
~/.opn-cli/<site>.yml (api_key/secret + url + internal-CA ca:), --config is
required. The split-horizon .internal records and public-name host-overrides
live in each router's Unbound, so `unbound host list/create/update/delete` is
how you inspect and fix them:

  opn-cli --config ~/.opn-cli/hanzalova.yml   unbound host list
  opn-cli --config ~/.opn-cli/kosherinata.yml unbound host list

Cross-referenced from reverse-proxies.md §2 as the tool to reach for when a
mesh client resolves a name to the wrong host — exactly the rob.fyi case.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016fKZzDpvjiJ9eYbPGgJvUP

reverse-proxies.md

@@ -41,6 +41,12 @@ A service can be reached two ways, and they are **not** interchangeable:
 This is why dual-audience services get **two vhosts** on the same proxy — one public
 (LE), one internal (`lair` CA) — usually sharing one webroot and one upstream.
 
+> **Debugging a wrong-host resolution.** When a mesh client reaches the wrong site (wrong
+> cert / wrong content), the culprit is usually a split-horizon record in the site
+> router's Unbound — a missing `*.internal` override, or a stale host-override sending a
+> public name to the wrong proxy. Inspect and fix it with `opn-cli` (`generic.md` §11
+> Network): `opn-cli --config ~/.opn-cli/<site>.yml unbound host list`.
+
 ## 3. Per-vhost cert choice
 
 | vhost audience | name | cert | doc |