docs(pyrowave): document 4:4:4 + HDR and add an interactive bitrate calculator

- New "4:4:4 and HDR" section: what each mode buys, the ~1.6× / +15% bitrate
  cost, that HDR needs a Windows host today (Linux capture has no HDR source),
  and that the two combine (~1.9× the 4:2:0 SDR rate).
- Interactive <BitrateCalculator> (registered in the MDX components map):
  resolution (presets or custom), frame rate, 4:2:0/4:4:4, SDR/HDR -> the
  estimated Automatic pin, bits/pixel, per-frame size, and which link tier it
  needs. Formula mirrors the host's resolve_bitrate_kbps_for exactly.
- Expanded the bandwidth table with 120 Hz rows; note the big modes want 5/10 GbE.
- Document PUNKTFUNK_PYROWAVE_MAX_MBPS (cap the open-loop pin on a constrained
  link) in configuration.md.
- pyrowave.md -> .mdx so the page can host the component.

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

docs-site/content/docs/configuration.md

@@ -90,6 +90,7 @@ See your desktop page ([KDE](/docs/kde), [GNOME](/docs/gnome)) for when to set t
 | `PUNKTFUNK_FEC_PCT` | `N` (percent) | Forward-error-correction redundancy for lossy links (the default is sensible for a normal LAN). Higher = more loss-resilient, more bandwidth. |
 | `PUNKTFUNK_10BIT` | `1` · `0` *(default on)* | HEVC Main10 / HDR. **On by default** — the host permits 10-bit; a session goes 10-bit only when the client advertises it (behind the client's HDR setting). Set `0` to force 8-bit. **Windows host only** (the Linux host stays 8-bit). |
 | `PUNKTFUNK_444` | `1` · `0` *(default on)* | Full-chroma HEVC 4:4:4 (Range Extensions) — sharper text/desktop, no chroma loss. **On by default** on the host; the client's own 4:4:4 setting (default off) is the real switch. Set `0` to force 4:2:0. **punktfunk/1 native only** (Moonlight stays 4:2:0), HEVC-only, honored only when the client advertises 4:4:4 **and** the GPU supports it (probed; NVENC is the validated path — VAAPI/AMF/QSV decline). Independent of 10-bit. |
+| `PUNKTFUNK_PYROWAVE_MAX_MBPS` | `N` (Mbps) | Cap the [PyroWave](/docs/pyrowave) Automatic bitrate pin, for a host on a link that the open-loop pin can outrun (e.g. 4:4:4 + HDR at 5120×1440@240 pins ~5.3 Gbps, over a 5GbE link). Unset = no cap. Only affects Automatic (bitrate `0`) PyroWave sessions; an explicit client bitrate bypasses it. |
 | `PUNKTFUNK_DSCP` | `1` | Opt-in DSCP / `SO_PRIORITY` QoS tagging on the media sockets. No-op on the wire on Windows without a qWAVE policy. |
 | `PUNKTFUNK_OH264_THREADS` / `PUNKTFUNK_OH264_GOP` | `N` | Software (openh264) encoder tuning: encode threads (default 2 — latency over throughput) and GOP length (default 0 = encoder-auto). Only relevant with `PUNKTFUNK_ENCODER=software`. |
 

docs-site/content/docs/pyrowave.mdx

@@ -27,23 +27,52 @@ either side can't, the session silently falls back to the normal codec ladder.
 
 ## What it costs
 
-Bandwidth. At the codec's ~1.6 bits-per-pixel operating point (4:2:0, 60 fps):
+Bandwidth. At the codec's ~1.6 bits-per-pixel operating point (4:2:0, SDR):
 
 | Mode | Bitrate |
 |---|---|
 | 1280×800 @ 60 (Deck) | ≈ 100 Mbps |
 | 1920×1080 @ 60 | ≈ 200 Mbps |
+| 1920×1080 @ 120 | ≈ 400 Mbps |
 | 2560×1440 @ 60 | ≈ 355 Mbps |
+| 2560×1440 @ 120 | ≈ 710 Mbps |
 | 3840×2160 @ 60 | ≈ 800 Mbps |
+| 3840×2160 @ 120 | ≈ 1.6 Gbps |
 
-120 Hz doubles these, 4:4:4 multiplies them by ~1.6, and an HDR (10-bit) session adds ~15 %.
-Gigabit Ethernet tops out around 940 Mbps of payload, so 4K60 wants 2.5GbE (or a lower
-rate). **Do not run this over Wi-Fi** — that's what HEVC/AV1 are for.
+Frame rate scales the rate linearly, [4:4:4](#444-and-hdr) multiplies it by ~1.6, and an
+[HDR](#444-and-hdr) (10-bit) session adds ~15 %. Estimate any combination:
 
-PyroWave follows the same 4:4:4 and HDR settings as HEVC/AV1: a session negotiates
-full-chroma 4:4:4 when your client's 4:4:4 setting is on, and HDR (BT.2020 PQ, carried in
-16-bit planes) when the host's display pipeline is HDR — currently the Windows host only
-(the Linux host's capture path has no HDR source yet, so Linux-hosted sessions are SDR).
+<BitrateCalculator />
+
+Gigabit Ethernet tops out around 940 Mbps of payload, so 4K60 wants 2.5GbE and the big
+4:4:4 / HDR / high-refresh modes want 5GbE or 10GbE. **Do not run this over Wi-Fi** — that's
+what HEVC/AV1 are for.
+
+## 4:4:4 and HDR
+
+PyroWave carries **full-chroma 4:4:4** and **HDR** the same way it carries everything else —
+intra-only, every frame a keyframe — so the low-latency and clean-loss properties above hold
+in these modes too. Both are negotiated per session from your client's settings, exactly like
+HEVC/AV1; nothing PyroWave-specific to turn on beyond picking the codec.
+
+- **4:4:4 (full chroma).** With your client's **4:4:4** setting on, the session encodes chroma
+  at full resolution instead of subsampled 4:2:0 — sharp coloured text, thin UI lines, and
+  red/blue edges that 4:2:0 softens. It costs ~1.6× the bitrate (chroma compresses better than
+  luma, so it is less than the 2× the extra samples imply). Available on Linux and Windows
+  hosts.
+- **HDR (10-bit, BT.2020 PQ).** With HDR on and an HDR host display pipeline, the session
+  carries a 10-bit BT.2020 PQ signal in 16-bit planes and adds ~15 % to the bitrate. **HDR
+  needs a Windows host today** — the Linux host's capture path has no HDR source yet, so
+  Linux-hosted sessions are SDR (4:4:4 still works).
+- The two combine: a 4:4:4 **and** HDR session applies both factors (~1.6 × 1.15 ≈ 1.9× the
+  4:2:0 SDR rate). The Apple and Rust clients decode whatever the session negotiated — 4:2:0
+  or 4:4:4, SDR or HDR — with no extra setup.
+
+At the top end this gets demanding: 4:4:4 + HDR at a super-ultrawide 5120×1440@240 pins around
+5.3 Gbps, which is more than a 5GbE link carries. On a link that can't keep up, either set an
+explicit lower bitrate on the client or cap the host's Automatic pin with
+[`PUNKTFUNK_PYROWAVE_MAX_MBPS`](/docs/configuration) — otherwise the overshoot just becomes
+dropped packets.
 
 ## Turning it on