docs: update status with mesh gap analysis findings

Key insight: best-in-class crypto but unproven mesh efficiency.
Priority actions: complete S4, measure MLS sizes, design MLS-Lite.

docs/status.md

@@ -1,5 +1,33 @@
 # Status Log
 
+## 2026-03-30 — Mesh Protocol Gap Analysis
+
+### Completed
+- Created `docs/plans/mesh-protocol-gaps.md` — honest assessment of QuicProChat vs. Reticulum/Meshtastic/Briar
+- Created `docs/src/design-rationale/mesh-protocol-comparison.md` — technical comparison document
+- Updated `docs/positioning.md` — sharper messaging + honest limitations
+- Identified critical gaps:
+  1. **MLS overhead too large for LoRa** — KeyPackages are 500-800 bytes, SF12 MTU is 51 bytes
+  2. **KeyPackage distribution unsolved** — MLS needs server, mesh has no server
+  3. **No lightweight mode** — need "MLS-Lite" for constrained links
+  4. **No real hardware testing** — all LoRa code runs against mocks
+
+### Key Insight
+QuicProChat has **best-in-class crypto** but **unproven mesh efficiency**. Meshtastic and Reticulum have **weak crypto** but **battle-tested mesh**. We need to close the efficiency gap without sacrificing crypto properties.
+
+### Priority Actions
+1. **S4: Multi-hop routing** — complete core mesh (in progress)
+2. **Measure actual sizes** — benchmark MLS KeyPackage, Welcome, Commit sizes
+3. **Design MLS-Lite** — lightweight symmetric mode for constrained links
+4. **Real hardware test** — procure SX1262 boards, test actual LoRa
+
+### Open Design Questions
+- How to distribute KeyPackages over mesh without server?
+- What's the right crypto/efficiency tradeoff for SF12 LoRa?
+- Should we implement LXMF compatibility for Reticulum interop?
+
+---
+
 ## 2026-03-30 — Sprint 6: LoRa transport & integration demo
 
 ### Completed