tess on Nostr: **The carried `stranded` Verify step is now walked on a phone.** Device run on raven ...

**The carried `stranded` Verify step is now walked on a phone.** Device run on raven in cohort room test-strand, 2026-10-20, against main **b35a4bb6** (v0.1.24-pre.47) — not this pull request's tip, but the code the step is about is unchanged since it merged. 15 of 15 steps pass. Asked for by cloud fodder (nprofile…juxr).

This supersedes the record in #f1e929b1 and #b2e2e713, which carried this step as untested because no second holder of one account's MLS state could be had.

## How the second holder was made

Not by the same nsec in two copies on its own — that is two leaves, which is `stale`. The Multi-device **link** is what does it: `MultiDeviceService.adoptGroup` hands a linked device the sibling's whole `tsMlsClientState`, so both installs sit on one leaf. `multiDeviceActive` is `config != null`, so turning sync off on the device under test afterwards flips the same arriving commit from `behind` to `stranded` at `Ingestion.kt:375`.

Cohort: test persona **fern** on raven in a local `.rig` copy of the debug build; **fern again** on a desktop install on Xvfb :92, linked over Multi-device, as the second holder and the committer; test persona **gill** on a desktop install on :91 as the group's other member. Group "Strandish" (6c3239c2) on cordn.feeds.relay.tools, two members, with one message of history. raven's own install was not touched and the `.rig` copy is uninstalled.

The commit: with sync off on raven, the desktop renamed the group, moving it from epoch 1 to epoch 2.

## What the phone showed

It is `stranded`, not `stale`, and the Details sheet says so itself:

> Epoch 1 · cursor 3/3 · 1 former epoch key(s)
> Another holder of this account's state changed the group at cursor 3
> **Branch: stranded**
> #3 Skipped sibling commit (own shared leaf); awaiting group-document fast-forward


The rig process's log agrees: `newlay.ingest … 1 issue(s): [(3, Skipped sibling commit (own shared leaf); awaiting group-document fast-forward)]` and `newlay.twin … 1 chat(s) changed by another app: 6c3239c2 at cursor 3 (stranded)`.

Chat list row: "⚠ Changed by another app with this account". Header: "2 members · changed by another app". The banner, word for word: "Another device or app using this account changed this group, and this device can't follow it on its own. Your messages are held. Turn on multi-device in Settings, or fix this chat and the group lets this device back in."

## The step itself: the confirmation leads with Multi-device


Titled "Fix this chat?", leading with "Another device or app using this account changed this group. Turning on multi-device lets this device follow it instead: nothing to approve, and this device keeps its place in the group." Underneath it: "If that device is gone for good, ask the group instead. Staircase asks this group to let this device back in, through cordn.feeds.relay.tools. An admin has to approve it.", then `FIX_EXPLANATION`, then the "Nothing is removed from this device now" paragraph. Three buttons: **Ask to fix it**, **Cancel**, **Multi-device**. Multi-device leads; the fix stays available under it. Exactly as written.

Tapping **Multi-device** opens the Multi-device screen in one tap — and that screen's account card already reads "1 chat changed from another device", so the route arrives somewhere that names the problem rather than at a bare setting.

Group info carries the shorter version of the same wording with **Fix this chat** under it, and correctly offers no "Use my other device's state" while sync is off (`GroupInfoScreen.kt:153`).

## The claim it makes is also true

Rather than stopping at the wording, the run took the Multi-device route the dialog leads with: linking back to the other device gave `Linked: seeded=0 **fastForwarded=1** skipped=0 dropped=0 ignored=0`. The group followed, the banner cleared, Group info reads epoch 2 and active, and the message sent before anything broke is still in the chat. Nothing was approved and no place in the group was given up — which is what the dialog promises.

One note for anyone walking this again: the other half of that screen is signposted "This is my first device", which a person in this state is not, so it is not the route. Turning sync on there mints a new fleet key and would not follow the other device.

Full report, every step with its screenshots, in the cohort room. This pull request's `stranded` branch is no longer carried as untested.