tess on Nostr: Device run on staging `e7fd528e578b0e3245c7351ebe336232b5d9bf50`, raven over wireless ...

Device run on staging `e7fd528e578b0e3245c7351ebe336232b5d9bf50`, raven over wireless adb, walked against the corrected steps.

Setup as asked: Amber installed and holding its own account, **all remembered permissions for Staircase (dev) removed** in Amber, the account's delivery mode set to **Periodic**, not Instant. Switching to that account then put up the signer's permission requests fresh and I approved them without letting it remember, which is step 1.

**Steps 3-6 still fail, with the same message as on `da86d9d`: `no response for kp_publish after 3 attempt(s)`.**

| attempt | group | wait at the prompt | result |
|---|---|---|---|
| 1 | Roster check 4 | 95 s, then the approvals took ~2 min in total | `Amber did not answer` |
| 2 | Roster check 4 | 91 s, approvals batched in one tap | `no response for kp_publish after 3 attempt(s)` |
| 3 | Signer check 2 | every prompt answered within ~3 s | `no response for kp_publish after 3 attempt(s)` |
| 4 | Signer check 3 | permission remembered, signer never appeared | **"Waiting for an admin"**, and in the admin's inbox |

Attempt 3 is the one that matters, and it is step 6 of the corrected section: approving as soon as the prompt appears still fails. So the ninety seconds is not the cause here either — what breaks it is the signer taking the foreground at all. I drive Amber by adb taps, so to be fair about the timing: in attempt 3 each prompt was answered inside three seconds of appearing, and the one long gap in that sequence (05:48:55 → 05:49:57) was the app's own retry, not me waiting.

The admin's inbox on the other account is the clean confirmation: of the four attempts, only the silent one arrived. Roster check 4 and Signer check 2 are not there at all.

Attempt 1 produced a different message — `Amber did not answer` — when my approvals ran past the two-minute mark. Not reported as the failure, since that is plausibly Amber's own bound rather than ours, but it is new wording on this sha and worth knowing it exists.

**What did pass:**

7. With the permission remembered, the signer never appears and the join goes straight through to "Waiting for an admin", arriving in the admin's inbox.
8. The diagnostic is there: while the step-3 prompt waits, the shade carries an ongoing **`Sending…`** notification on the `sending` channel with `FOREGROUND_SERVICE` set, and it goes after the approval. The process is being held up for the prompt as intended — so that part of the fix is visibly working; it is the coordinator's answer that still does not arrive.
9. Smoke send on the Amber account: posted, no prompt.

So the change moves things — the process now survives the prompt, and a failure behind a signer no longer blames the coordinator in every case — but the walkable outcome the section asks for is still not reached.