build: add receiver-only configuration and a Pi install script

The receiver does not need the sender's PipeWire/xdg-desktop-portal
capture stack, which small ARM boards neither have nor want. Add a
-Dsender=false meson option that skips the capture backend and the
sender pipeline (SC_HAS_SENDER guards in main.cpp/pipelines.cpp);
receiver-only builds refuse --send with a clear message while
--receive and --discover work unchanged.

scripts/install-receiver.sh targets such boards (e.g. Raspberry Pi
Zero 2 W): installs build and runtime dependencies via apt, checks the
compiler for C++20 <format> support before the long build (GCC 13+,
i.e. Raspberry Pi OS Trixie), builds SDL3 from source when the distro
does not package it, compiles a receiver-only binary, runs the test
suite, installs to /usr/local/bin, and enables avahi-daemon.

Also refresh the stale README (phases, dependencies, current
roadmap, Pi receiver section).

Validated in both configurations: meson test 5/5 each; the
receiver-only build has no PipeWire/portal references, refuses --send
cleanly, and --discover works headlessly.

.agents/MEMORY.md

@@ -23,6 +23,14 @@ loopback; current phase is Phase 7.
   both 127.0.0.1 and ::1.
 - **Discovery dedupe**: one entry per (service_name, signaling_port) — a
   host with many interfaces otherwise registers dozens of address variants.
+- **Receiver-only builds** (`-Dsender=false`, meson option): skip the
+  capture backend and sender pipeline (`SC_HAS_SENDER` guards in
+  main.cpp/pipelines.cpp; `--send` refuses cleanly in such builds).
+  `scripts/install-receiver.sh` uses this to install on small ARM boards
+  (user's Raspberry Pi Zero 2 W receiver) without PipeWire/portal deps,
+  building SDL3 from source when the distro lacks it. Requires GCC 13+
+  (`<format>`). Validated on x86_64: builds, tests 5/5, --discover works,
+  --send refuses with a message.
 - **mDNS operational lesson (hit during validation)**: `kill -9` on a
   process holding an avahi registration leaves stale daemon records; the
   service then browses but never resolves (timeout for every peer) until
@@ -117,9 +125,12 @@ None.
 ## Open questions
 
 - GUI framework (Qt6 vs. none / CLI only) — deferred to later phase.
-- Hardware acceleration strategy (VAAPI / Vulkan Video / NVENC) — evaluate after
-  software encode path works.
-- IPv6 at the transport layer — revisit when LAN streaming lands (Phase 6+).
+- Hardware acceleration strategy (VAAPI / Vulkan Video / NVENC) — evaluate
+  after software encode works; note the Pi Zero 2 W receiver use case makes
+  hardware **decode** (V4L2/MMAL) the more urgent half.
+- IPv6 at the transport layer — RESOLVED in Phase 6: dual-stack everywhere
+  (AF_UNSPEC resolution, IPV6_V6ONLY=0 listeners); validated over both
+  families.
 
 ## Forward-looking review notes (for later phases)