docs(hyperliquid): add connect steps to Peering Access

[Jared-dz]

Summary

The Peering Access page tells customers how to request peering but not what to do once they get their peer details. This adds a Connect your node section after "Request peering":

1. Gossip config: root_node_ips set to the peer, try_new_peers: false, split_client_blocks: true, chain: Mainnet, with a short table on why each setting is there.
2. Firewall: allow inbound TCP and UDP 4001–4002 from the peer IP. The page explains why: the peer dials back to verify the node, and if that is blocked the connection opens but no data arrives.
3. Restart the node after every config change.
   A disk and bandwidth note follows the settings table. Mempool output is several hundred GB to about 1 TB of disk writes per day. Inbound bandwidth is lower because gossip is compressed on the wire. It also tells readers to set a retention policy.
4. Checks: one established connection to the peer, applied block in the log, mempool_txs growing. There are two admonitions, one for "connected but no data" and one for "no fallback to public peers".

Notes:

• The peer IP is a placeholder (<PEER_IP>). The page already says peer details are sent after approval. A hardcoded IP would go stale once there is more than one user peering host.
• chain: Mainnet is included because Hyperliquid's own examples set it, and it is what was run in testing.
• "Restart after every change" comes from a test on 2026-09-29 against a live non-validating node (visor binary 112). The running node does reread override_gossip_config.json, but some changes did not take effect without a restart, and nothing is logged either way.
• The disk and bandwidth figures come from a 2-minute sample on the test host (2026-09-30, peered with the user peering node, mempool on). That sample showed mempool_txs at 4.29 MB/s (~371 GB/day), all ~/hl/data output at 8.61 MB/s (~744 GB/day) and NIC inbound at 1.26 MB/s (~109 GB/day). They match public figures: QuickNode reports ~1.1 TB/day of raw mempool volume, and Ironflow reports ~700 GB/day of node writes before cleanup. The note gives a range rather than exact numbers because one short sample isn't enough to publish.
• Only the English page is edited. The auto-translate workflow handles the other locales.

Not in this PR: the "How it works", "Uptime" and "Autoscaling" sections still describe the Block Proxy tier. That no longer matches how peering is delivered (a dedicated user-peering host behind our privileged node). That needs a separate rewrite, and a decision on how much topology to publish.

Testing

• The page was checked against a real setup: test host 18.183.43.22 is peered with the user peering node using this exact config and firewall rule. It is at chain head with mempool_txs growing.
• mkdocs build passes with no new warnings. The rendered page has the section, the highlighted JSON block and both admonitions.

[Jotatavo]

Looks good, lgtm