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.

src/pages/manage/network-routes/use-cases/by-scenario/site-to-vpn.mdx

@@ -39,12 +39,6 @@ upstream firewall. Without this, the overlay peer drops the traffic at its
 access control. See [Outbound SNAT requirement](#outbound-snat-requirement).
 </Warning>
 
-<Warning>
-The overlay peer will always observe the **routing peer's NetBird IP** as
-the source of the request, not the clientless device's local IP. See
-[Source IP Behavior](#source-ip-behavior) below for the details.
-</Warning>
-
 ## Prerequisites
 
 - A [NetBird cloud account](https://app.netbird.io/) or [self-hosted instance](/selfhosted/selfhosted-quickstart)
@@ -306,20 +300,6 @@ its upstream firewall), as shown in Step 3. This is a real, observable
 limitation rather than a quirk: without the SNAT, the dashboard masquerade
 flag has no effect on the wire.
 
-## Source IP Behavior
-
-Because of the outbound SNAT above, the target peer always observes the
-**routing peer's NetBird IP** as the source — regardless of which clientless
-device on the site initiated the connection.
-
-Preserving the original site source IP all the way to the target peer is
-**not currently possible**. Removing the access policy that targets the
-destination peer does not "open" it; it simply tears down the wireguard
-pairing between the routing peer and the destination, and the connection
-fails to establish at all. Future versions of [Networks](/manage/networks)
-may expose Resource groups as policy sources for the Site-to-VPN direction
-— track the Networks documentation for updates.
-
 ## Troubleshooting
 
 **Connection times out from the clientless device.**