docs: document the Android receiver app (Phase 8)

README: phone-as-second-screen section (build, install, sender usage,
multi-monitor caveat). RUNBOOK: Android build/test procedure, device-test
commands, and the API-36 platform quirks found during validation.
PHASES: Phase 8 milestones, all validated. MEMORY: current phase state
and the hard-won Android/portal lessons.

README.md

@@ -139,6 +139,38 @@ sudo scripts/pi-hotspot.sh off      # back to normal router Wi-Fi
 While active the Pi is reachable at `10.42.0.1`; on the sender, join the
 hotspot's Wi-Fi and run `screencast --send`.
 
+## Android receiver: a phone as the second screen
+
+A native receiver app (Kotlin, minSdk 30) lets a phone act as the second
+receiver — and with a USB-C DisplayPort-alt-mode cable, the phone screen
+mirrors straight to HDMI. The app speaks the same signaling + RTP protocol,
+so the sender needs no changes.
+
+```sh
+cd android
+gradle :app:assembleDebug          # or :app:installDebug with a device attached
+adb install app/build/outputs/apk/debug/app-debug.apk
+```
+
+Launch the app (it advertises `_screencast._tcp` and shows its IP + ports),
+then on the sender:
+
+```sh
+screencast --send --peer <phone-ip>:5005
+```
+
+Notes:
+
+- The sender downscales to the phone's display resolution automatically
+  (from the signaling answer).
+- The phone renders letterboxed (fit-within), fullscreen, screen kept on.
+- The app needs only the `INTERNET` permission; no camera/location.
+- mDNS discovery works on the same L2 segment; across subnets use `--peer`
+  (the app prints its IP and the exact fallback command).
+- `--target monitor` captures the portal's default output — on multi-monitor
+  Hyprland/GTK-portal setups that may not be the one you want; use
+  `--target window` and pick a window on the target display.
+
 ## Architecture
 
 See `docs/ARCHITECTURE.md` for module boundaries and design rules.
@@ -147,11 +179,11 @@ See `docs/ARCHITECTURE.md` for module boundaries and design rules.
 
 Development is split into phases in `docs/PHASES.md`.
 
-Current phase: **Phase 7 — Resilience and polish**. PLI recovery, the
-jitter buffer, hardware decode, and the GUI/waybar front-ends are complete
-and validated on a real two-machine setup (desktop → Raspberry Pi Zero 2 W
-over Wi-Fi); deferred items are the VAAPI hardware encode probe and
-packaging.
+Current phase: **Phase 8 — Android receiver app** (complete): the Kotlin
+receiver app streams to a phone (validated on a Fairphone 6, phone → HDMI
+via USB-C DP-alt-mode). Phase 7 items (PLI, jitter, hardware decode,
+GUI/waybar) are complete and validated; deferred items remain the VAAPI
+hardware encode probe and packaging.
 
 ## License