docs(routing-peers): apply outstanding feedback and expand inbound links (#730)

* docs(routing-peers): apply outstanding review feedback

- Drop the unverified Cloud-specific settings subsection (AWS/GCP/Azure
  bullets) and the related AWS source/destination pitfall bullet
- Spell out "high availability" in the Masquerade note for clarity

* docs(routing-peers): expand inbound cross-links to How Routing Peers Work

Surface the routing peer primer from 11 high-leverage pages so readers
landing in a configuration or scenario guide can find the mental model
without having to backtrack through the sidebar.

- Index pages (manage/networks, manage/network-routes): move the
  cross-link from the page top into the Routing Peer(s) subsection,
  where it sits adjacent to existing routing-peer guidance
- exit-nodes scenario: cross-link inside the Routing Peer subsection,
  anchored at #exit-node-mode
- internal-dns-servers: cross-link under Domain Resources and Routing
  Peer DNS, anchored at #routing-peer-dns-resolution
- Procedural and comparison pages (access-control, by-scenario VPN-to-Site
  guides, site-to-site overview, Kubernetes operator, routing peers in
  Kubernetes): cross-link near the page top with section-specific anchors

* docs(routing-peers): spell out HA across the primer and cross-link notes

- Index-page cross-link notes (manage/networks, manage/network-routes):
  expand "HA" to "high availability" in the bullet list
- Primer page: spell out the three remaining HA references in the High
  availability section and Common pitfalls; use "highly available peers"
  as the adjective form

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

@@ -88,15 +88,9 @@ A containerized routing peer needs `NET_ADMIN`. The Kubernetes manifest also add
 
 The routing peer must have direct network reachability to the resources it serves. This is the most common cause of failed deployments in cloud environments: the peer ends up in the wrong subnet, the wrong security group, or on the wrong side of a VPC peering boundary.
 
-### Cloud-specific settings
-
-- **AWS.** Disable source/destination check on the EC2 instance acting as the routing peer.
-- **GCP.** Enable IP forwarding at the instance level (`--can-ip-forward`).
-- **Azure.** Enable IP forwarding on the NIC.
-
 ## High availability
 
-Multiple routing peers can serve the same network or route. Behavior depends on the **metric** you assign each routing peer in the dashboard. There are no tunable thresholds — the metric is the only HA control.
+Multiple routing peers can serve the same network or route. Behavior depends on the **metric** you assign each routing peer in the dashboard. There are no tunable thresholds — the metric is the only high availability control.
 
 ### Primary / failover (different metrics)
 
@@ -112,7 +106,7 @@ Useful when routing peers are geographically distributed and you want each clien
 
 ### Failure domains
 
-Place HA peers in different failure domains within the same network: separate AZs in cloud, separate hypervisors or hosts on-prem.
+Place highly available peers in different failure domains within the same network: separate AZs in cloud, separate hypervisors or hosts on-prem.
 
 ## Masquerade
 
@@ -126,7 +120,7 @@ Turn masquerade off when:
 With masquerade off, you must add a return route on the destination network pointing the NetBird CIDR (default `100.64.0.0/10`) at the routing peer.
 
 <Note>
-Masquerade can only be turned off on Linux routing peers. HA also stops working with masquerade off, because return traffic must flow back through one specific routing peer's LAN address — the destination network has no way to follow a failover.
+Masquerade can only be turned off on Linux routing peers. High availability also stops working with masquerade off, because return traffic must flow back through one specific routing peer's LAN address — the destination network has no way to follow a failover.
 </Note>
 
 ## Access control behavior
@@ -205,10 +199,9 @@ Specifics:
 
 ## Common pitfalls
 
-- Skipping the AWS source/destination check disable.
 - Network Route with no ACL Groups, granting blanket access.
 - Policy to a network resource works, but SSH to the routing peer itself is denied because the input chain has no matching policy.
-- HA peers in the same AZ, defeating the purpose of HA.
+- Highly available peers in the same AZ, defeating the redundancy.
 - Mixing domain and IP-range resources in the same network.
 - Exit node missing the ICMP policy, so clients can't connect to the routing peer in the first place.
 - DNS port mismatch when an account has a mix of pre-0.59 and post-0.59 peers.

src/pages/manage/networks/index.mdx

@@ -4,10 +4,6 @@ NetBird creates a secure peer-to-peer mesh network where devices running the Net
 
 However, installing the agent on every machine is not always feasible. Networks solve this by letting you route traffic to entire LANs, office networks, or cloud VPCs without requiring the NetBird agent on each device.
 
-<Note>
-For the mental model behind routing peers — how traffic flows, host requirements, HA, masquerade, the forward-vs-input-chain rule, and hardening — see [How Routing Peers Work](/manage/networks/how-routing-peers-work).
-</Note>
-
 <p>
     <img src="/docs-static/img/manage/networks/netbird-network-routes.png" alt="high-level-dia" className="imagewrapper-big"/>
 </p>
@@ -46,6 +42,10 @@ To get alerted when a routing peer goes offline, enable the **Routing Peer Disco
 A network resource policy grants access to the network **behind** the routing peer, not to the routing peer machine itself. If you need to access services running on the routing peer (for example, Pi-hole, Home Assistant, or a monitoring dashboard), add the routing peer to a group and create a peer-to-peer [access control policy](/manage/access-control) with that group as the destination.
 </Note>
 
+<Note>
+For the mental model — how traffic flows, host requirements, high availability, masquerade, and the forward-vs-input-chain rule — see [How Routing Peers Work](/manage/networks/how-routing-peers-work).
+</Note>
+
 ### Resources
 
 Resources are the machines, services, or subnets you want to access within your internal network. You can define resources as:

src/pages/manage/networks/use-cases/by-scenario/access-home-devices.mdx

@@ -4,6 +4,10 @@ import { Note } from '@/components/mdx'
 
 This guide shows how to access your home network devices from anywhere using the Networks feature.
 
+<Note>
+For the mental model — see [How Routing Peers Work — Mental model](/manage/networks/how-routing-peers-work#mental-model-how-traffic-flows).
+</Note>
+
 ## What You'll Achieve
 
 After following this guide, you'll be able to access your home NAS, media server, home automation, or any device on your home network from your laptop or phone—anywhere in the world.

src/pages/manage/networks/use-cases/by-scenario/cloud-to-on-premise.mdx

@@ -4,6 +4,10 @@ import { Note } from '@/components/mdx'
 
 This guide shows how to connect cloud workloads to on-premise databases and services using the Networks feature.
 
+<Note>
+For the mental model — see [How Routing Peers Work — Mental model](/manage/networks/how-routing-peers-work#mental-model-how-traffic-flows).
+</Note>
+
 ## What You'll Achieve
 
 After following this guide, your cloud applications will be able to securely access on-premise databases, APIs, and services without exposing them to the public internet.

src/pages/manage/networks/use-cases/by-scenario/remote-worker-access.mdx

@@ -4,6 +4,10 @@ import { Note } from '@/components/mdx'
 
 This guide shows how to enable remote workers to securely access office resources using the Networks feature.
 
+<Note>
+For the mental model — see [How Routing Peers Work — Mental model](/manage/networks/how-routing-peers-work#mental-model-how-traffic-flows).
+</Note>
+
 ## What You'll Achieve
 
 After following this guide, employees will be able to access office servers, applications, and services while working remotely—without exposing those resources to the internet.