docs(dist): end-user install front door + serve/pairing/firewall accuracy fixes

Make the host docs match the real distribution path and the actual CLI. Reviewed by a
multi-agent pass (6 editors against one verified fact sheet + an accuracy reviewer); its
findings (a wrong client-Recommends claim, a native-concurrency overstatement) folded in.

- Install front door: new README "Install (host)" method-picker + docs-site/install.md
  (+ nav), routing each distro to its package registry; source build demoted to a fallback.
- Registry-first install: ubuntu-gnome/ubuntu-kde now lead with the apt registry (not a
  cargo build); bazzite leads with the Gitea RPM registry (was COPR/source). Source builds
  moved to an appendix.
- CLI accuracy: serve --native arms pairing from the web console (NOT --allow-pairing, which
  with --require-pairing/--max-concurrent is m3-host-only); --open disables mandatory pairing.
  host-cli/configuration/pairing/quickstart/troubleshooting corrected; mgmt API documented as
  always HTTPS+token. Native host serves one session at a time (extras queue) — not multi.
- Firewall: real ports documented (native UDP 9777 + the ephemeral data port caveat +
  GameStream ports) for Debian + Arch (ufw + nftables), not just Bazzite.
- Sync/accuracy: punktfunk-client (GTK4) presented as a shipping client (not "roadmap"),
  punktfunk-client-rs as the headless tool; host Recommends punktfunk-web only (not the
  client); COPR chroots f43/44; bootc header says Gitea registry not COPR.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs-site/content/docs/troubleshooting.md

@@ -10,8 +10,11 @@ description: Common problems setting up or using a punktfunk host, and how to fi
 - Host and client must be on the **same network/subnet**. Discovery uses mDNS, which doesn't cross
   routed subnets or most VPNs-without-multicast. As a fallback, add the host by **IP address** in your
   client.
-- A firewall on the host can block it. The native protocol uses UDP port **9777** (plus the data
-  port); GameStream/Moonlight uses its standard ports. Allow them on the host's firewall.
+- A firewall on the host can block it. The native protocol's control plane uses UDP port **9777**. The
+  per-session **data plane** uses an *ephemeral* UDP port negotiated at connect time (currently
+  random) — for a strict firewall, open a UDP range or move the data port. GameStream/Moonlight uses
+  TCP **47984/47989/48010** + UDP **47998–48010** + ENet UDP **47999**. Allow them on the host's
+  firewall.
 
 ## `nvidia-smi` says it can't communicate with the driver
 
@@ -56,8 +59,8 @@ Then log out and back in. On other distros this is `sudo usermod -aG input $USER
 
 ## Pairing is rejected / the client can't connect
 
-- The host **requires pairing** by default. Arm pairing (web console, or `--allow-pairing`), then
-  enter the PIN on the client. See [Pairing & Trust](/docs/pairing).
+- The host **requires pairing** by default. Arm pairing from the web console, then enter the PIN on
+  the client. See [Pairing & Trust](/docs/pairing).
 - If you re-installed the host, its identity changed — re-pair the client.
 
 ## Stutter, drops, or high latency
@@ -65,8 +68,9 @@ Then log out and back in. On other distros this is `sudo usermod -aG input $USER
 - Lower the **bitrate**. On a busy or Wi-Fi link, the requested bitrate may be too high — the Apple
   app's [speed test](/docs/configuration#bitrate) picks a safe value; with Moonlight, set it manually.
 - Prefer a **wired** connection or 5 GHz Wi-Fi between host and client.
-- Streaming to **many devices at once** shares the GPU encoder; cap concurrency with
-  `--max-concurrent`.
+- Streaming to **many devices at once** shares the GPU encoder. The production host
+  (`serve --native`) handles one native session at a time, with extra clients queued; heavy load is
+  usually bitrate-bound, so lower the bitrate first.
 
 ## Still stuck?