feat(steam): M4 complete — C-ABI send path, Decky UX, Apple/Android parity

Finish the client side of the Steam Controller / Steam Deck pipeline.

- C-ABI (core abi.rs): PunktfunkRichInputEx — a size-prefixed superset of
  PunktfunkRichInput that can express the second trackpad (surface), a distinct
  click vs touch, signed coords + pressure — plus
  punktfunk_connection_send_rich_input2 (the struct_size ABI-skew-guard
  precedent). The only way a C client (Apple/embedders) can emit a TouchpadEx;
  the legacy struct + send_rich_input stay byte-for-byte. punktfunk_core.h
  regenerated.

- Decky (clients/decky): a "Steam Deck" gamepad type in Settings + an unmissable
  Disable-Steam-Input instruction shown when it's selected (in Game Mode Steam
  Input holds 0x1205, so the SDL HIDAPI Steam driver can't open the Deck's
  controls until the user disables Steam Input for the shortcut). Plus a
  best-effort, feature-detected disableSteamInputForShortcut() in launchStream —
  never blocks/throws; the manual toggle is the documented source of truth.

- Apple parity (PunktfunkConnection.swift): GamepadType.steamController/steamDeck
  (wire 5/6) + name parsing, so the resolved type round-trips. Capture is blocked
  (GameController never surfaces a 0x28DE HID device).

- Android parity (Gamepad.kt): PREF_STEAMCONTROLLER/STEAMDECK + the Valve 0x28DE
  PIDs in prefFor(). Rich-input capture stays out of scope (no rich-input plane
  yet) — standard buttons/sticks resolve to the host's Steam Deck pad.

Rust workspace clippy/fmt/test green; Decky src/ typechecks clean (only a
pre-existing @decky/api dep resolution error remains); Swift/Kotlin compile on
their CI. The full pipeline is now BUILT; what remains is validation that needs
hardware we don't have (a running Steam on the host, a live Deck client, the
Moonlight paddle regression). Not pushed.

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

design/steam-controller-deck-support.md

@@ -1,10 +1,28 @@
 # Rich Steam Controller & Steam Deck support
 
-> **Status:** **M0–M3 GREEN + M4 desktop-capture done (2026-06-29).** The host side is complete:
+> **Status:** **M0–M4 GREEN — the full Steam Controller/Deck pipeline is built (2026-06-29).** Host:
 > the virtual `hid-steam` Deck binds, is byte-exact, is a wired backend (`PUNKTFUNK_GAMEPAD=
-> steamdeck`), and the protocol carries the rich Steam inputs. The **Linux + Windows SDL clients now
-> capture + send** them. Remaining M4: the Decky Disable-Steam-Input UX, Apple/Android parity, and
-> the C-ABI `PunktfunkRichInputEx`/`send_rich_input2` (Apple/embedder send path).
+> steamdeck`), and the protocol carries the rich inputs. Clients: the Linux + Windows SDL clients
+> capture + send them; the Decky plugin has the Steam Deck mode + Disable-Steam-Input UX; the C-ABI
+> has the `TouchpadEx` send path; Apple/Android round-trip the type. Remaining is **validation, not
+> construction** (see below) + the deferred extras (M5 fallback-remap polish, M6 SteamOS-host
+> conflict check, M7 Windows UMDF Steam driver).
+>
+> **M4 (complete) result:** *(desktop capture — see the prior entry.)* Plus: **C-ABI** —
+> `PunktfunkRichInputEx` (size-prefixed superset) + `punktfunk_connection_send_rich_input2` (the
+> `struct_size` skew-guard precedent; the only way a C client emits `TouchpadEx`); legacy
+> `PunktfunkRichInput`/`send_rich_input` byte-for-byte; `punktfunk_core.h` regenerated. **Decky** —
+> a "Steam Deck" gamepad option + an unmissable **Disable-Steam-Input** instruction (shown when
+> selected) + a best-effort feature-detected programmatic flip in `launchStream` (never throws; the
+> manual toggle is the source of truth). **Apple/Android parity** — `GamepadType.steamController/
+> steamDeck` (Swift) + `PREF_STEAMCONTROLLER/STEAMDECK` + the `0x28DE` PIDs in `prefFor` (Kotlin), so
+> the type round-trips; capture stays out of scope there (iOS GameController won't surface a `28DE`
+> device; Android has no rich-input plane yet). Rust workspace clippy/fmt/test green; Decky `src/`
+> typechecks clean; Swift/Kotlin compile on their CI.
+>
+> **Pending VALIDATION (whole feature, needs hardware we don't have):** (1) recognition of the
+> virtual Deck by a **running Steam** on the host; (2) a **live Deck/Steam Controller client** actually
+> sending paddles/trackpads/gyro; (3) the **Moonlight paddle regression** from the M3 xpad-map change.
 >
 > **M4 (desktop client capture) result:** `clients/{linux,windows}/src/gamepad.rs` (the SDL services)
 > now: set the SDL HIDAPI Steam hints (`SDL_JOYSTICK_HIDAPI_STEAMDECK`/`_STEAM`) so SDL opens Valve