Bring the parity table back in line with what has been run

Three rows had drifted from the code, in the direction that matters — claiming
less than exists, which sends people to build things that are already there.

`SiteConfig` on Android is not missing: `SiteConfig.kt` holds the three
deployment shapes, `MainActivity` has the relay field, and the screen shows an
`identity-mode` label naming which kind of server it is *before* a passphrase
is typed. Marked ⚪ regardless.

Sign-up on the managed and shared shapes now has a test rather than nothing —
`LiveSignUpFleetTest` — which compiles but has not been run, so the row stays
🟡. The distinction is worth keeping: written and unrun is not built and
unexercised, and neither is done.

Send/receive text was verified app-to-app this time, not app-to-harness, and
the evidence is recorded with the log lines it came from.

Also added the two environment traps that cost the most time today, because
neither is visible in a test log: XCUITest degrades into "Timed out while
synthesizing event" and 1700-second runs when macOS background daemons are
saturating the machine, and Spotlight indexes DerivedData unless the path ends
`.noindex`.

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

PARITY.md

@@ -66,13 +66,13 @@ From `Sources/Auth/*` and `Sources/Views/Sign*`.
 | Feature | Android |
 |---|:--:|
 | Sign up — local self-hosted | ✅ verified against `relay1` through the UI |
-| Sign up — managed / shared self-hosted | 🟡 built, not yet exercised end to end |
+| Sign up — managed / shared self-hosted | 🟡 `LiveSignUpFleetTest` written, compiles, **unrun** |
 | Sign in, session restore | ✅ |
 | Sign out (erases the vault key) | ✅ |
 | Password reset request + confirm | ✅ on the sign-in screen |
 | Change password | ✅ signs the device out, because that is what it does |
 | Delete account | ✅ confirms in place, erases the phone too |
-| Relay picker / `SiteConfig` equivalent | ⚪ |
+| Relay picker / `SiteConfig` equivalent | ✅ `SiteConfig.kt`, a `relay` field, and an `identity-mode` label |
 | Deterministic local-relay KDF salt | ⚪ | 
 | Multi-homing (publish + read home records) | ⚪ |
 
@@ -88,7 +88,7 @@ From `E2E/E2EInbox.swift`, which is the real feature list.
 
 | Feature | Android |
 |---|:--:|
-| Send / receive text | ✅ verified app ↔ separate program, through a real relay |
+| Send / receive text | ✅ **app ↔ the iOS app**, through a real relay — see below |
 | Inbox polling | ✅ every 5 s while open; no push channel exists |
 | Multi-device fan-out | ✅ one envelope per device, partial delivery reported |
 | History at rest | ✅ encrypted, keyed by person not device |
@@ -185,6 +185,33 @@ the live tests already cover and the door is what was missing.
 It found two real gaps on its first run: sign-out was reachable only from the
 contact list rather than from Account, and several controls sat below the fold.
 
+## Cross-platform, 2026-08-25
+
+**iOS → Android is proven, through both UIs.** The iOS app signed up on
+`relay1`, added the Android account as a contact, and sent; the Android
+instrumentation logged the exact text back:
+
+    ANDROID_HANDLE=andcross073349
+    ANDROID_RECEIVED=hello from iOS 073413
+
+That is the direction the parity table's "separate program" row used to mean,
+now done against the real client rather than a harness.
+
+**Android → iOS is delivered but not yet *seen*.** The headless `:interop:peer`
+decrypted a message from the iOS app and its reply came back from the relay as
+`{"delivered":1,"failed":0,"to":239}` — so the envelope reached the iOS
+device. What has not been watched is the iOS UI rendering it.
+
+⚠️ The obstacle is the machine, not the protocol. XCUITest starts failing with
+"Timed out while synthesizing event" and runs stretch from ~200s to over 1700s
+when macOS background daemons are busy — `lsdiagnose`, `mds_stores` and
+`wifianalyticsd` were between them taking several cores, with load averages
+around 69. Nothing in a test log names that as the cause. Check `uptime` before
+believing a slow or flaky XCUITest run.
+
+⚠️ Point `-derivedDataPath` at a directory ending `.noindex`. Spotlight will
+otherwise index every build product, which is a large share of the above.
+
 ## Known flakiness
 
 ⚠️ **The emulator's network drops occasionally** — seen twice as "Failed to