feat: M1 lumen-core (FEC/crypto/packet/session + C ABI) and workspace scaffold

Ground-up low-latency streaming stack per docs/implementation-plan.md. M1 is
complete and tested; Linux host backends are cfg-gated stubs to be filled in on
real hardware (M0/M2).

lumen-core (built + tested on macOS/aarch64 — 21 tests):
- fec: ErasureCoder over GF(2^8) (reed-solomon-erasure, Moonlight-compatible)
  and GF(2^16) Leopard-RS (reed-solomon-simd, the >1 Gbps wall-breaker); proptested
- packet: zero-copy #[repr(C)] framing, multi-block, FEC-aware reassembly
- crypto: AES-128-GCM with per-direction nonce salts + sequence-as-AAD
- session: host submit / client poll hot paths + input; loopback & UDP transports
- abi: opaque handles, versioned LumenConfig, panic guards; cbindgen-generated header
- acceptance: Rust loopback+proptest and a C harness that links the staticlib

Scaffold (compiles green on all platforms): lumen-host (vdisplay/capture/encode/
inject/web/pipeline seams under cfg(linux)), lumen-client-rs, tools/{loss-harness,
latency-probe}, Apple/Android client stubs, Gitea CI, docs.

Hardened against a multi-agent adversarial review (13 verified findings fixed,
regression-tested): reassembler memory-DoS bounds + block-consistency validation,
GCM nonce-reuse direction separation, ABI struct_size guard + range checks, FEC
shard-length guards, shard_payload datagram bound, key zeroization + Debug redaction.

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

clients/android/README.md

@@ -0,0 +1,20 @@
+# lumen Android client (later)
+
+Kotlin UI + MediaCodec (decode) + a thin JNI layer over the `lumen-core` C ABI.
+
+## Wiring
+
+1. Build the core as a shared library per Android ABI:
+   ```sh
+   rustup target add aarch64-linux-android armv7-linux-androideabi x86_64-linux-android
+   cargo build -p lumen-core --release --target aarch64-linux-android   # liblumen_core.so
+   ```
+   (Use `cargo-ndk` to handle the NDK toolchain/linker.)
+2. JNI shim: small C/Rust glue mapping `lumen_*` to Kotlin `external fun`s, bundling
+   `liblumen_core.so` into the APK's `jniLibs/`.
+3. Kotlin: client `LumenSession` → `lumen_client_poll_frame` on a decode thread → feed
+   `MediaCodec` → render to a `SurfaceView` aligned to the display refresh.
+
+## Status
+
+Placeholder — scheduled after the Apple client (M5).

clients/apple/README.md

@@ -0,0 +1,22 @@
+# lumen Apple client (M5)
+
+Swift + VideoToolbox (decode) + Metal (present) + SwiftUI, linking `lumen-core` through
+the generated C ABI — **no glue layer**. Imports `include/lumen_core.h` via a module map.
+
+## Wiring
+
+1. Build the core as a static or dynamic library for Apple targets:
+   ```sh
+   rustup target add aarch64-apple-ios aarch64-apple-darwin
+   cargo build -p lumen-core --release --target aarch64-apple-darwin   # liblumen_core.a / .dylib
+   ```
+2. Expose the C ABI to Swift with a module map (`module.modulemap` here) that points at
+   the checked-in header `../../include/lumen_core.h`.
+3. In Swift: create a client `LumenSession`, `lumen_client_poll_frame` on a display-link
+   thread, feed the access unit to a `VTDecompressionSession`, present the `CVImageBuffer`
+   with Metal aligned to the screen's refresh (frame pacing, plan §7).
+
+## Status
+
+Scaffold. The client half of `lumen_core` (`poll_frame`, FEC recovery, reassembly) is
+complete and tested; this target adds the platform decode + present.

clients/apple/module.modulemap

@@ -0,0 +1,7 @@
+// Exposes the lumen-core C ABI to Swift as `import LumenCore`.
+// Point Xcode's "Import Paths" (SWIFT_INCLUDE_PATHS) at this directory, and link
+// liblumen_core.a (or .dylib) built via `cargo build -p lumen-core --target <apple>`.
+module LumenCore {
+    header "../../include/lumen_core.h"
+    export *
+}