Document behavior of multiple separate exit nodes (#954)

* docs: state what actually happens with multiple separate exit nodes

Replaces the 'does not work: ... no coordinated selection' claim in
Regional Exit Nodes with the verified behavior: separate exit nodes
appear as independent choices in the device's exit node selector, the
client auto-selects the alphabetically first name (metrics and latency
play no part), and there is no failover between exit nodes - a device
whose selected exit node loses its routing peer keeps it selected and
loses internet entirely, even across reconnects. Adds the matching
non-overlapping-distribution-groups caveat to the per-group placement
advice, and aligns 'exit node entry' wording to plain 'exit node'.

* docs: scope multi-exit-node selection behavior to Auto Apply

* docs: deduplicate multi-exit-node caveats

* docs: state the one-auto-applied-exit-node-per-device rule

Author: SunsetDrifter

src/pages/use-cases/remote-access/exit-nodes.mdx

@@ -122,13 +122,15 @@ Set up one routing peer in each region as described in the [configuration steps]
 
 ### 2. Add both peers to the same exit node
 
-In the exit node's configuration, add both routing peers and leave the metric identical on both. Adding them as two separate exit node entries does not work: metrics and nearest-peer selection only apply between routing peers of the same route, so separate entries give every device both default routes with no coordinated selection.
+In the exit node's configuration, add both routing peers and leave the metric identical on both.
+
+Adding the regions as two separate exit nodes does not work, and fails in a way that is easy to miss. Metrics and nearest-peer selection only apply between routing peers of the same exit node. Separate exit nodes instead appear on each device as independent choices in its exit node selector, and with [Auto Apply](#exit-node-selection-and-auto-apply) enabled (the default) the client activates exactly one: whichever exit node's name sorts first alphabetically. Metrics and latency play no part in that choice. If the activated exit node's routing peer goes offline, the device keeps it selected and loses internet access entirely, even while another exit node's routing peer is online and connected. One exit node with multiple routing peers gives you selection and failover; separate exit nodes give you neither.
 
 <p>
-    <img src="/docs-static/img/manage/network-routes/use-cases/exit-nodes/regional-exit-nodes-equal-metrics.png" alt="One exit node entry with two routing peers at equal metrics, distributed to the remote-workers group" className="imagewrapper-big"/>
+    <img src="/docs-static/img/manage/network-routes/use-cases/exit-nodes/regional-exit-nodes-equal-metrics.png" alt="One exit node with two routing peers at equal metrics, distributed to the remote-workers group" className="imagewrapper-big"/>
 </p>
 
-The finished state: one exit node entry, both regional routing peers under it with the same metric, and the distribution group on each.
+The finished state: one exit node, both regional routing peers under it with the same metric, and the distribution group on each.
 
 ### 3. Keep the distribution group and access policy scoped
 
@@ -148,7 +150,7 @@ On an east-coast device, run `netbird status -d`: the peer carrying the `0.0.0.0
 
 This is nearest-exit selection plus automatic failover, not load balancing: each device follows its own lowest-latency exit node, and traffic is not spread evenly across the exit nodes. See [Latency switching](/manage/networks/how-routing-peers-work#latency-switching-equal-metrics) for the selection mechanism.
 
-Latency-based selection is also not a guarantee of *which* exit node a given user lands on. If a rule must always hold, such as certain users always exiting in a specific country, use separate exit nodes with per-group distribution, or posture checks as in [Geo-Based Exit Node Routing](#geo-based-exit-node-routing) below.
+Latency-based selection is also not a guarantee of *which* exit node a given user lands on. If a rule must always hold, such as certain users always exiting in a specific country, use separate exit nodes with per-group distribution, or posture checks as in [Geo-Based Exit Node Routing](#geo-based-exit-node-routing) below. Make sure each device receives at most one exit node with [Auto Apply](#exit-node-selection-and-auto-apply) enabled: enable it on one exit node per distribution group, and keep those groups from overlapping — more than one auto-applied exit node on a device is the failure mode described in step 2 above. Offer any additional exit nodes with Auto Apply disabled; users can switch between exit nodes manually in the client either way.
 
 Traffic to your own sites is unaffected by any of this: routes to specific internal ranges are more specific than `0.0.0.0/0`, so devices reach those resources directly through the routing peer that advertises them, regardless of which exit node carries their internet traffic.