docs: redraw the Networks diagram and illustrate forward vs input chain

Replace the Networks overview image on the Networks and How Routing
Peers Work pages with a redrawn diagram: peers reach a routing peer
through a WireGuard tunnel, and per-resource access policies on the
routing peer allow specific ports, while a resource with no policy is
unreachable. The old footnote referred to Network Routes HA; the new one
describes adding more than one routing peer to a Network.

Replace the ASCII block in "Through the peer, or to the peer?" with a
diagram of the two paths (network resource policy in the forward chain,
peer-to-peer policy in the input chain), and add the same diagram to
"Two chains, two policy types".

The previous image is kept because the Implement Zero Trust page still
uses it.

src/pages/manage/networks/how-routing-peers-work.mdx

@@ -37,7 +37,7 @@ NetBird offers two ways to configure routing peers. Both are actively maintained
 ## Mental model: how traffic flows
 
 <p>
-    <img src="/docs-static/img/manage/networks/netbird-network-routes.png" alt="Routing peer bridging NetBird overlay to a private network" className="imagewrapper-big"/>
+    <img src="/docs-static/img/manage/networks/networks-overview.png" alt="Three NetBird peers on the overlay network connect through a WireGuard tunnel to a routing peer in a private network. Access policies on the routing peer allow a database on TCP 5432, a web app on TCP 443, and an RDP workstation on TCP/UDP 3389; a printer with no policy is unreachable." className="imagewrapper-big"/>
 </p>
 
 The walkthrough below describes the **Linux kernel-mode** path, where forwarding and firewalling happen in the kernel via `nftables` / `iptables`. On other platforms, NetBird performs the same logical steps in a userspace filter, but the implementation differs.
@@ -172,6 +172,10 @@ This is the subtlest part of the model and the source of most policy mistakes.
 - **Forward chain.** Packets routed *through* the peer to backend resources. Network resource policies (Networks) and ACL Groups (Routes) apply here.
 - **Input chain.** Packets destined to the routing peer's own IP. [Peer-to-peer policies](/manage/access-control/manage-network-access) apply here.
 
+<p>
+    <img src="/docs-static/img/manage/networks/through-or-to-the-routing-peer.png" alt="Two paths compared. Through the routing peer: a network resource policy, evaluated in the forward chain, lets a client reach a web app behind the routing peer on TCP 443. To the routing peer: a peer-to-peer policy, evaluated in the input chain, lets a client reach SSH on the routing peer's NetBird IP on TCP 22." className="imagewrapper-big"/>
+</p>
+
 If users need to reach both the resources behind a routing peer **and** services running on the routing peer itself (Pi-hole, monitoring, jump-host SSH), you need one policy of each kind.
 
 **Example.** A routing peer fronts the `10.10.0.0/16` office network and also runs Grafana on TCP/3000 plus SSH on TCP/22. To let the `Engineers` group reach both, create two policies:

src/pages/manage/networks/index.mdx

@@ -21,10 +21,10 @@ Throughout this page, a capitalized **Network** means the configuration object y
 If you remember one thing, remember this: **a NetBird Network is a map of part of your infrastructure, drawn onto your overlay network.** The **resources** are the destinations, the **access policies** are the gatekeepers that decide who may pass, and the **routing peers** are the roads that carry traffic to each destination.
 
 <p>
-    <img src="/docs-static/img/manage/networks/netbird-network-routes.png" alt="A NetBird client reaching resources on a private network through a routing peer" className="imagewrapper-big"/>
+    <img src="/docs-static/img/manage/networks/networks-overview.png" alt="Three NetBird peers on the overlay network connect through a WireGuard tunnel to a routing peer in a private network. Access policies on the routing peer allow a database on TCP 5432, a web app on TCP 443, and an RDP workstation on TCP/UDP 3389; a printer with no policy is unreachable." className="imagewrapper-big"/>
 </p>
 
-*Left to right: a peer in a source group clears an access policy, reaches the routing peer, and connects to a resource behind it.*
+*Left to right: peers reach the routing peer through a WireGuard tunnel, and access policies on the routing peer decide which resources behind it each peer can reach. The printer has no policy, so nothing reaches it.*
 
 ## The four building blocks
 
@@ -100,13 +100,9 @@ One subtlety causes most policy mistakes. A network resource policy permits traf
 
 If a resource stays unreachable even though the policy looks right, [Troubleshooting resource connectivity](/help/troubleshooting-resource-connectivity) helps you find which layer is dropping the traffic.
 
-```
-THROUGH the routing peer  →  forward chain  →  network resource policy
-   your client ──tunnel──► routing peer ──────► resource behind it
-
-TO the routing peer        →  input chain    →  peer-to-peer policy
-   your client ──tunnel──► routing peer  (its own SSH, dashboard, …)
-```
+<p>
+    <img src="/docs-static/img/manage/networks/through-or-to-the-routing-peer.png" alt="Two paths compared. Through the routing peer: a network resource policy, evaluated in the forward chain, lets a client reach a web app behind the routing peer on TCP 443. To the routing peer: a peer-to-peer policy, evaluated in the input chain, lets a client reach SSH on the routing peer's NetBird IP on TCP 22." className="imagewrapper-big"/>
+</p>
 
 <Note>
 For the full kernel-level traffic walkthrough, host requirements (IP forwarding, container capabilities), masquerade internals, and the forward-vs-input-chain rule in depth, see [How Routing Peers Work](/manage/networks/how-routing-peers-work).