Merge branch 'release-0.7' into 'main'

Release 0.7 — group member lists leave the server

See merge request paulhitt/flamenet-messenger-android!7

app/build.gradle.kts

@@ -33,8 +33,8 @@ android {
         // ⚠️ Android also refuses to install an APK whose `versionCode` is
         // lower than the installed one, so a code that goes backwards makes a
         // release uninstallable for everybody already on the higher number.
-        versionCode = 6
-        versionName = "0.6"
+        versionCode = 7
+        versionName = "0.7"
         testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
     }
 

interop/src/main/kotlin/io/flamenet/interop/Main.kt

@@ -131,11 +131,16 @@ private fun handle(req: JSONObject): JSONObject = when (req.getString("cmd")) {
 /**
  * A device and the bundle a relay would serve for it.
  *
- * `proto` is 1 and no PQ block is published, because this engine has no ML-KEM
- * yet. That is a real limitation stated as data rather than hidden: the web
- * engine's `negotiate()` sees a v1 peer and says so, and the harness asserts
- * exactly that — so the day Kotlin gains PQ, this bundle changing is what makes
- * the assertion fail and get updated.
+ * `pq` chooses what this bundle advertises: `proto` 3 with a signed ML-KEM
+ * prekey, or `proto` 1 with no PQ block at all. Both are shapes a real relay
+ * serves — the fleet still holds released builds that speak v1 — and a driver
+ * that could only produce the newest one would stop covering the older paths on
+ * the day they matter most.
+ *
+ * ⚠️ This is the LOW-level path, wiring X3DH and the ratchet together by hand.
+ * The `session_*` commands go through `E2ESession` instead, which is what the
+ * app calls, and which owns the negotiation decision. Version numbers reported
+ * here are X3DH's; the app's envelope version comes from the session layer.
  */
 private fun newDevice(req: JSONObject): JSONObject {
     // 🔴 A v1 bundle is still a thing this engine must be able to publish, and