Vendor iroh with upstream's hot-fix for the path-open queue

Ayni has been growing until Android kills it, and the cause is upstream and
already known. `RemoteStateActor` re-queues a failed path-open into
`pending_open_paths`, and the 333 ms retry calls `open_path_on_all_conns` for
each entry — which retries the address on *every* connection to that peer, and
every connection still at the path-id cap pushes it back again. One entry
becomes C entries per tick. There is no dedup and no cap.

Two issues are open against it, neither fixed:

  #4390  bug, milestone Sprint P. 24 GB single allocation on macOS.
  #4509  Windows, RSS past 100 GB, "ALLOCATION FAILURE: 171798691840 bytes".
  #4124  closed, the related open_path warning spam.

A comment on #4390 reports it on iOS through iroh-ffi, crashing three times in
six hours "including a couple of network roams (WiFi <-> cellular)" — which is
this application exactly, and connects it to the network-change work in D32.

Measured here with heapprofd on a follower up 54 minutes:

    largest SINGLE allocation   834,695,168 bytes  (796 MB)
    total allocated on stack      1.13 GB in 150 s

That doubling is why it looks like bursts rather than a leak: `grow_amortized`
briefly holds the old buffer and the new one, so RSS jumps and then falls back,
and summing net allocation finds almost nothing. `max(size)` finds it.

iroh 1.2.0 carries identical logic — only a variable renamed — so upgrading does
not help. Checked rather than assumed.

So iroh 1.1.0 is vendored with one deduplicating, capped enqueue, taken verbatim
from the maintainer-facing hot-fix in #4390 so it lifts out cleanly when the
real one lands. `vendor/iroh/DIASWARM-PATCH.md` records all of this and how to
remove it.

**NOT yet claimed as fixed.** Eleven minutes on phone B holds native heap flat at
~87 MB where the unpatched build reached 200 MB by six minutes and 348 MB by
fifteen. But the failure mode is a burst after forty-plus minutes, and this has
twice been called early on windows that were too short. It is under measurement.

`crates/diaswarm-peer` is deliberately left on stock iroh: a control that should
still grow if the patch is what stopped the phones.

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

Author: alex-poor

crates/diaswarm-android/Cargo.lock

@@ -46,3 +46,12 @@ strip = true
 lto = true
 codegen-units = 1
 opt-level = "z"
+
+# **IROH IS VENDORED AND PATCHED HERE.** Not a fork for its own sake: upstream
+# grows `pending_open_paths` geometrically until the allocator fails, which is
+# what has been killing the follower overnight. One deduplicating function,
+# taken verbatim from the maintainer-facing hot-fix in iroh#4390, both of whose
+# issues are still open. `vendor/iroh/DIASWARM-PATCH.md` has the measurements
+# and the instructions for removing this again.
+[patch.crates-io]
+iroh = { path = "../../vendor/iroh" }

crates/diaswarm-android/Cargo.toml

@@ -28,3 +28,12 @@ p2panda-encryption = "=0.7.1"
 # empty (keys_replicate.rs). Same version/features p2panda-store already pulls,
 # so it unifies rather than adding a second sqlx.
 sqlx = { version = "=0.8.6", features = ["runtime-tokio", "sqlite"] }
+
+# **IROH IS VENDORED AND PATCHED HERE.** Not a fork for its own sake: upstream
+# grows `pending_open_paths` geometrically until the allocator fails, which is
+# what has been killing the follower overnight. One deduplicating function,
+# taken verbatim from the maintainer-facing hot-fix in iroh#4390, both of whose
+# issues are still open. `vendor/iroh/DIASWARM-PATCH.md` has the measurements
+# and the instructions for removing this again.
+[patch.crates-io]
+iroh = { path = "../../vendor/iroh" }

crates/diaswarm-net/Cargo.lock

@@ -0,0 +1 @@
+{"v":1}

crates/diaswarm-net/Cargo.toml

@@ -0,0 +1,6 @@
+{
+  "git": {
+    "sha1": "fddf1a4ce29f92c6651eccff68fb366007b9be7d"
+  },
+  "path_in_vcs": "iroh"
+}