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'.

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 the client auto-selects exactly one: whichever exit node's name sorts first alphabetically. Metrics and latency play no part in that choice, and the device never fails over from one exit node to another. If the selected 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. When you use separate exit nodes this way, keep their distribution groups from overlapping: a device that receives more than one exit node auto-selects whichever one's name sorts first alphabetically, and will not fall back to another exit node if that one's routing peer goes down. Devices that should choose an exit node themselves (for example, optional regional exits) are the one case where separate exit nodes are right, with users selecting one manually in the client.
 
 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.