docs: add Site-to-VPN scenario guide (#748)

* docs: add Site-to-VPN scenario guide

New dedicated guide for letting clientless devices on a local network
initiate connections to NetBird peers (the reverse of VPN-to-Site).
Covers static-route and DNAT options, DNS resolution via dnsmasq, and
explains why the target peer always observes the routing peer's NetBird
IP as the source.

- Add src/pages/manage/network-routes/use-cases/by-scenario/site-to-vpn.mdx
- Wire it into NavigationDocs.jsx
- Update the site-to-site overview table row to point at the new page
- Replace the stub Site-to-VPN subsection in site-to-site-office.mdx
  with a pointer to the new guide

* docs(site-to-vpn): correct source-IP section, add firewall and interface notes

- Source IP Behavior: remove the option that suggested emptying the
  destination peer's policies. That doesn't preserve source IP; it just
  tears down the wireguard pairing. Replace with an honest "not possible
  with legacy Network Routes."
- Step 3: call out that hosts with FORWARD-DROP firewalls (UFW, firewalld)
  need an explicit ACCEPT rule between the site interface and wt0.
- Option B: prefix the DNAT step with `ip -br addr` so customers find the
  right site-facing interface instead of assuming eth0.
- Step 1: use "Name" for the setup key field instead of the route-only
  "Network Identifier".

* docs(site-to-vpn): tighten prereqs, firewall step, and source-IP wording

- Drop generic prereqs (account, routing peer hardware, target peer)
- Reduce Step 3 to the host-firewall FORWARD rule
- Label Networks-feature Site-to-VPN as 'not possible' rather than limited
- Rename topology arrow to 'NetBird Overlay'
- Clarify masquerade lives on the routing peer in troubleshooting

* docs(site-to-vpn): switch primary path to Networks; document outbound SNAT requirement

Verified in the lab that Networks supports Site-to-VPN with the same
shape as Network Routes (Resource + Routing Peer + peer-group policy).
The differentiating factor is not the feature but the routing peer
platform: NetBird's masquerade flag does not install a working outbound
SNAT on non-Linux peers or in userspace mode, so the user must configure
it explicitly on the routing peer or upstream firewall.

Doc changes:
- Lead with Networks; Network Routes is now framed as an equivalent
  alternative rather than the only option
- New Step 3 dedicated to the outbound SNAT (Linux iptables, pfSense /
  OPNsense, MikroTik examples)
- New section "Outbound SNAT requirement" explaining why the destination
  peer's access control rejects unrewritten site IPs and where the
  dashboard masquerade flag is and isn't sufficient
- Up-front Warning calls out the platform requirement so customers don't
  silently misconfigure
- Troubleshooting entry updated to point at SNAT counters and tcpdump
- Updated Source IP Behavior section to reflect that the behavior is the
  same on both Networks and Network Routes

Parent page changes:
- /use-cases/site-to-site: Scenario Support table now shows Site-to-VPN
  as Yes on both Networks and Network Routes; "Which Scenario Do I Need"
  row points at both implementations

* docs(site-to-vpn): make static route the only Step 6 path; move DNAT to appendix

The static-route approach is the canonical setup; the per-service DNAT
option is a fallback for sites where routing changes aren't possible.
Treat it that way in the doc to keep the main flow linear.

- Step 6 now describes only the static-route approach (former Option A)
- Add a one-line pointer at the end of Step 6 to the appendix for sites
  where the route can't be set
- Move the DNAT instructions to a new appendix at the bottom of the page
- Simplify Test Connectivity to a single curl
- Trim the Option-A/Option-B framing from the Troubleshooting "Connection
  times out" entry

* docs(site-to-vpn): drop Source IP Behavior section

The "Outbound SNAT requirement" section already covers why the source IP
ends up as the routing peer's NetBird IP; a separate Source IP Behavior
section was repeating the same point and adding a speculative paragraph
about future Networks support. Drop both, plus the up-front Warning that
pointed at the removed section.

* docs(site-to-vpn): drop the Networks-vs-Network-Routes note

The guide is written around Networks; the side-note suggesting Network
Routes as an alternative path adds noise without value. The Step 4 inline
note keeps the Network Routes equivalent for anyone who needs it.

* docs(site-to-vpn): drop the inline Network Routes equivalent note

The guide is Networks-only now. Pointing readers at Network Routes mid-flow
just creates two paths to maintain without serving the reader who's
following the steps in front of them.

* docs(site-to-vpn): move page under Networks → Use Cases

The page describes a Networks-based setup; living under Network Routes
mis-categorised it.

- git mv to /manage/networks/use-cases/site-to-vpn.mdx (as a direct
  child of Use Cases, not under By Scenario)
- Navigation: remove entry from Network Routes → By Scenario, add under
  Networks → Use Cases
- Redirect old URL (/manage/network-routes/use-cases/by-scenario/site-to-vpn)
  to new URL, permanent
- Update in-tree links in use-cases/site-to-site/index.mdx and
  network-routes/use-cases/by-scenario/site-to-site-office.mdx

* docs(site-to-site): drop Network Routes mentions for Site-to-VPN

The Site-to-VPN guide is Networks-only; the overview page shouldn't
still be listing Network Routes alongside it.

* docs(site-to-vpn): trust NetBird's automatic SNAT on Linux kernel mode

On Linux in kernel mode, NetBird installs the SNAT itself when masquerade
is enabled on the routing peer — the user does not need a manual iptables
rule. Reframe Step 3 around this:

- Linux: enable ip_forward only; NetBird does the SNAT
- Non-Linux (pfSense / OPNsense / MikroTik / Windows / macOS / userspace):
  configure manual outbound SNAT on the routing peer or upstream firewall
- Tighten the "Outbound SNAT requirement" appendix accordingly
- Move the explicit Linux iptables MASQUERADE rule into a troubleshooting
  fallback for the case where NetBird's automatic SNAT doesn't fire

* docs(site-to-vpn): drop sysctl ip_forward instruction on Linux

NetBird handles IP forwarding itself on Linux; the manual sysctl was
unnecessary noise. Keep the host-firewall FORWARD-ACCEPT note since
UFW/firewalld setups still need it.

* docs(site-to-vpn): route the account's /16, not the entire /10 CGNAT range

NetBird assigns each account one /16 block out of 100.64.0.0/10 (chosen
randomly, customisable). Routing the whole /10 sends unrelated CGNAT
addresses through the routing peer; the correct target is the account's
own /16.

Step 6 now:
- Explains the /16-per-account model with the 64-block context
- Shows how to read the account's /16 from `netbird status` on any peer
- Switches the Linux / Windows / DHCP-option-121 examples to a concrete
  /16 example (100.121.0.0/16) with a note to substitute your own

* docs(site-to-vpn): clarify when the target peer uses a setup key

Setup keys are for service / appliance peers; user peers (laptops,
workstations) enroll through SSO and inherit groups from existing
assignments. Reword the target-peer instruction to reflect that
distinction.

* docs(site-to-vpn): rename target peer to overlay-peer / overlay-peers

The previous backup-collector / backup-collectors naming carried
scenario-specific framing into the step examples. Use the generic
overlay-peer / overlay-peers throughout to keep the guide universal.

* chore: add trailing commas in Kubernetes nav entries

* Revert "chore: add trailing commas in Kubernetes nav entries"

This reverts commit d11b7eb7d0.

src/components/NavigationDocs.jsx

@@ -232,6 +232,10 @@ export const docsNavigation = [
                   },
                 ],
               },
+              {
+                title: 'Site-to-VPN',
+                href: '/manage/networks/use-cases/site-to-vpn',
+              },
             ],
           },
         ],