The reply round-trip can be pointed at a real answering peer

aReplyFromSomebodyElseAppearsInTheThread needs somebody replying as the
contact. That is the interop Peer in autoreply mode. The handle is a
runner argument now, defaulting to the standing peerjvmone, so the case
can target a throwaway peer created for one run.

Proven green this way: build interop with :interop:installDist, create a
peer on relay1, run autoreply, and run this case alone against it. It
must run ALONE. One autoreply peer pins the first fresh account it sees
and drops a second, so the two ChatFlow methods cannot share one peer in
a single invocation, which is why the whole class run leaves this case
red while the case on its own passes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

app/src/androidTest/kotlin/io/flamenet/messenger/app/ChatFlowTest.kt

@@ -54,7 +54,14 @@ class ChatFlowTest {
         } else {
             "https"
         }
-    private val peerHandle = "peerjvmone"
+    // The contact on the other side. `peerjvmone` is a standing account on
+    // relay1; the reply case needs somebody answering AS it, which is the
+    // interop Peer in `autoreply` (see PROVEN below). Override with
+    // -Pandroid.testInstrumentationRunnerArguments.peer=<handle>, and run the
+    // reply case ALONE: one autoreply peer pins the first fresh account it
+    // sees and drops a second one, so two ChatFlow methods cannot share it.
+    private val peerHandle: String
+        get() = InstrumentationRegistry.getArguments().getString("peer") ?: "peerjvmone"
     private lateinit var handle: String
 
     @Before