docs: add troubleshooting for router DNS rebinding protection

Some routers (confirmed on Verizon Fios/G3100) block the local-<office>
hostname from resolving because it's a public domain pointing at a
private LAN IP, which matches the DNS rebinding attack pattern. Document
the router-level fix (DNS Rebind Protection exception) and the per-machine
hosts-file workaround for both the Debian server and Windows staff PCs,
including the antivirus hosts-file-lock gotcha on Windows.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

README.md

@@ -657,6 +657,74 @@ sudo nginx -t && sudo systemctl reload nginx
 Staff can now use `https://local-<office>.mydentalofficemanagement.com` with a trusted padlock —
 no certificate warnings, no CA install on any PC.
 
+### Troubleshooting — router blocks the hostname (DNS rebinding protection)
+
+Some routers (this has been confirmed on Verizon Fios gateways, e.g. the G3100) refuse to resolve
+`local-<office>.mydentalofficemanagement.com` even though the DNS record is correct and public
+resolvers (`1.1.1.1`, `8.8.8.8`) answer it fine. Symptoms: `ping`/`dig` against the hostname fails
+or returns no answer when using the router as the DNS server, while `dig @1.1.1.1 <hostname>`
+returns the right LAN IP.
+
+Cause: the router's **DNS rebinding protection** blocks any public hostname that resolves to a
+private IP (`192.168.x.x`) — a heuristic meant to stop DNS rebinding attacks, which happens to
+match this setup's pattern (public domain → private LAN IP) exactly.
+
+Preferred fix: on the router's admin page (e.g. `https://192.168.1.1` for Fios), look under
+**Advanced → Network Settings → DNS Server** for a **DNS Rebind Protection** exception list, and
+add `local-<office>.mydentalofficemanagement.com`. If no exception list exists, disabling DNS
+Rebind Protection entirely also works, at the cost of that protection network-wide.
+
+If you don't have router access, override DNS resolution per machine with a hosts-file entry
+instead — this works because every OS checks its local hosts file before asking the router's DNS,
+so the query never reaches the router:
+
+**Debian/Linux server itself:**
+```sh
+sudo nano /etc/hosts
+```
+Add a line at the bottom (replace with this office's actual LAN IP and hostname):
+```
+192.168.1.229    local-<office>.mydentalofficemanagement.com
+```
+Save and exit — no service restart needed, `/etc/hosts` is checked before DNS automatically.
+
+**Windows staff PCs (PowerShell):**
+```powershell
+# 1. Open PowerShell as Administrator, then confirm it's actually elevated
+([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
+# must print True — if False, close this window and reopen via right-click "Run as administrator"
+
+# 2. Append the entry
+Add-Content -Path C:\Windows\System32\drivers\etc\hosts -Value "192.168.1.229    local-<office>.mydentalofficemanagement.com"
+
+# 3. Verify it saved
+Get-Content C:\Windows\System32\drivers\etc\hosts -Tail 3
+
+# 4. Flush the DNS cache and test
+ipconfig /flushdns
+ping local-<office>.mydentalofficemanagement.com
+```
+
+> **If `Add-Content` fails with "the process cannot access the file... being used by another
+> process,"** antivirus software (Malwarebytes, Avast/AVG "Hosts File Guard", McAfee, and some VPN
+> clients are known to do this) is locking the hosts file to prevent tampering. Temporarily
+> disable real-time protection, redo step 2, verify with step 3, then **re-enable antivirus** —
+> the hosts file entry itself doesn't need protection disabled to keep working, only to make the
+> edit.
+
+Editing Notepad directly instead of PowerShell is not recommended: saving
+`C:\Windows\System32\drivers\etc\hosts` without true elevation fails silently in some cases (the
+file appears saved but `LastWriteTime` never changes) — PowerShell's `Add-Content` surfaces a
+clear permission error instead, which is easier to diagnose.
+
+The real Let's Encrypt certificate from Step 5 keeps working normally regardless of how each
+client resolves the hostname — it was validated via DNS-01 against Cloudflare at issuance time,
+not by a live connection to the server, so staff still get a trusted padlock with no warnings.
+
+This is a per-machine workaround; the router-level exception above is preferred when possible
+since it fixes every device on the network in one place instead of requiring a hosts-file edit
+(and possibly an antivirus fight) on every PC.
+
 ---
 
 ## Twilio In-Browser Calling Setup (Dial Pad)