Add Troubleshooting relayed connections teaching page (#791)

* docs: add Troubleshooting relayed connections teaching page

Adds a help-section teaching doc that walks junior admins from
'Connection type: Relayed' to a fixed P2P connection (or a justified
stop): mental model, the four players (NAT/Signal/STUN/Relay), ICE
candidate reading, an elimination-based decision flow, a port-forwarding
escape hatch, a worked walkthrough, and when relay is the right answer.

Moves the troubleshooting-oriented sections (Checking Your Connection
Type, Tips for Improving P2P Success) out of Understanding NAT and
Connectivity, leaving it purely conceptual with pointers to the new
page. Adds sidebar entry and a pointer from troubleshooting-client.

* fix: correct nftables example for STUN outbound rule

The STUN service runs on UDP 80/443/3478/5555, but the example rule
allowed TCP/443. Also note that nftables resolves hostnames at
ruleset-load time only, which matters for a dynamic geo-distributed
endpoint pool.

src/pages/help/troubleshooting-client.mdx

@@ -73,7 +73,8 @@ the management server, or the signal server.
 As for Peers, the status will show the following information:
 
 * `Connection type`: P2P, Relayed, where relayed connections indicate a limitation in the network that prevents a direct
-  connection between the peers.
+  connection between the peers. To diagnose and fix a relayed connection, see
+  [Troubleshooting relayed connections](/help/troubleshooting-relayed-connections).
 * `Direct`: true/false, where true indicates a direct connection between the peers without a local proxy. This case is
   common when the local peer is allocating the relay connection.
 * `ICE candidate (Local/Remote)`: relay/host, where relay indicates that the local peer is using a relay connection and