On-site (GA network) detection is only mock-tested — validate for real on cybele/omega #48

Context

PR #45 adds automatic on-site/off-site detection so the fetcher picks the right SSH hop count without user config: on_site_network(device) in src/magnetics/data/fetch/network.py decides whether we're inside a device's site network and, if so, dials mdsip directly (tcp), skips the getMany batch attempt appropriately, and drops the cluster ProxyJump.

The heuristic is: socket.getfqdn() ends with the device's network.domain (e.g. gat.com for DIII-D, pppl.gov for NSTX), with a MAGNETICS_ON_NETWORK=0|1 env override.

The gap

The unit tests (tests/test_fetch_network.py) exercise the logic with a monkeypatched socket.getfqdn() — they verify the branch selection given a hostname, but never that the assumption holds on a real host. Specifically, untested:

• That socket.getfqdn() on an actual cybele / omega node actually returns a *.gat.com FQDN (and fast — no slow reverse-DNS stall).
• That the auto direct-TCP mdsip path works end-to-end when running on-site (no gateway tunnel).
• That the remote backend drops the ProxyJump correctly when launched from on the cluster (no self-jump).
• Behavior on the split-tunnel-VPN case the env override is meant to cover.

These can only be confirmed by running on the GA cluster, so they belong to the "make cybele-running work" effort rather than the local CI suite.

Suggested work

• Run the fetcher (both mdsthin --tcp-auto and remote) from cybele/omega and confirm the detection + hop-count choices.
• Capture the real on-site FQDN and add a note/fixture documenting it.
• If getfqdn() proves unreliable or slow on-site, fall back to a short-timeout direct-connect probe (attempt-then-fall-back-to-jump), which self-heals a misdetect.

Related: #17 (fast GUI remote pulls), #20 (connection-settings overhaul).