docs: accept all blocked-connection results and scope the exit-node guarantee

Author: SunsetDrifter

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

@@ -286,12 +286,12 @@ The design rests on one property, so test that property directly on the exit nod
 Then confirm the user-visible behavior from a device in `remote-workers`:
 
 - The allowed resources respond: a host in `10.60.0.0/20` and the host `10.70.5.20` are reachable.
-- The forbidden network does not: connections to addresses in `10.90.0.0/20` time out.
+- The forbidden network does not: connections to addresses in `10.90.0.0/20` fail. Depending on how the segment enforces egress, they time out, are rejected, or report an unreachable route; any of these is the correct result.
 - Internet traffic exits through the exit node: the device's public IP (for example with `curl ifconfig.me`) matches the exit node's public IP.
 
 ### What this does and does not do
 
-Users get precisely the two internal resources and a full tunnel, and the forbidden network stays unreachable even though every packet toward it still arrives at the exit node. The restriction is enforced by where the exit node lives, so no dashboard change, policy mistake, or client setting can widen it.
+Users get precisely the two internal resources and a full tunnel, and the forbidden network stays unreachable even though every packet toward it still arrives at the exit node. That restriction is enforced by where the exit node lives, so no dashboard change, policy mistake, or client setting can expose the forbidden network through it.
 
 It does not restrict what the data center routing peer exposes: that peer's host can reach `10.90.0.0/20`, and only its resource list and policies keep users out. Keep those scoped to exact prefixes and single hosts, and treat any new resource on that peer as a deliberate access decision.