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

Author: SunsetDrifter

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

@@ -124,7 +124,7 @@ Set up one routing peer in each region as described in the [configuration steps]
 
 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.
+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, 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 with two routing peers at equal metrics, distributed to the remote-workers group" className="imagewrapper-big"/>
@@ -150,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. 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.
+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 with [Auto Apply](#exit-node-selection-and-auto-apply) enabled activates 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: disable Auto Apply on them and let users select 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.