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/pairing.md

@@ -38,13 +38,13 @@ The PIN ceremony is the other path — useful for the *first* device (before the
 anything) or when you're at the client and the console isn't handy.
 
 Pairing has to be **armed** on the host before a client can pair (so a random device can't pair
-itself). Two ways:
+itself). On the production host (`serve --native`), this is done from the **web console**: open the
+host's management console, click to arm pairing, and the host displays a 4-digit PIN along with the
+list of paired devices. This works on a headless host over the network — there is no command-line flag
+to arm pairing on `serve`.
 
-- **Web console** *(recommended)* — open the host's management console, click to arm pairing, and it
-  shows the PIN and the list of paired devices. This is the easiest way and works on a headless host
-  over the network.
-- **Command line** — start the host with `--allow-pairing` (or `--require-pairing`); it prints a PIN
-  in its log when a client begins pairing.
+(The standalone headless test host, `m3-host`, takes `--allow-pairing`/`--require-pairing` on its
+command line instead; the production `serve --native` host arms pairing from the console.)
 
 Then, on the client:
 
@@ -57,8 +57,8 @@ By default, the native host **requires** pairing — only devices that have pair
 the right setting on a shared network: a device has to complete the PIN ceremony once before it can
 connect.
 
-If you're on a fully trusted single-user network and want to skip pairing, the host can be run open —
-but requiring pairing is strongly recommended.
+If you're on a fully trusted single-user network and want to skip pairing, start the host with
+`serve --native --open` — but requiring pairing is strongly recommended.
 
 ## Trust-on-first-use