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

Device run on staging `da86d9d991d8045d599d1a7a31b7ddc83708bd16`, raven over wireless adb, second member on a real client in two groups.

Eight of the ten walkable steps passed. **Step 6 failed**, in a way the step's own wording would not catch.

## What broke — a whitespace-only reply leaves the notification's reply box dead

Step 6 asks for "nothing sent, nothing added to the thread, the notification unchanged". The first two hold. The third does not.

Walked twice, same result both times:

1. Fresh chat notification in the shade, Reply tapped, box opened.
2. Typed three spaces (and on the recheck, two), tapped send.
3. Nothing is sent — the other member received nothing, and nothing appears in the notification's `MessagingStyle` thread. That part is right.
4. But systemui's reply box stays open, holding the spaces, with its spinner showing and `enabled="false"` in the view hierarchy. It does not close, and it cannot be typed into again.

It stays that way. I left it four minutes on the first run and a further minute on the recheck; it was still disabled. What clears it is the **next message arriving in that chat** — the notification is re-posted and the Reply action comes back enabled. Until then the person has one dead notification and no way to answer from it.

The cause is visible from the outside: systemui shows the pending spinner from the moment it fires the `RemoteInput` `PendingIntent` and waits for the app to update the notification. `NotificationReply` drops a blank reply and returns without re-posting, so nothing ever tells systemui the request is finished. A truly empty box does not do this — there systemui's own send control is inactive and the intent never fires, which is why the defect only shows on the whitespace variant the step puts in brackets.

Screenshot: `shots/da86d9d/41-blank-stuck.png`, and the reproduction at `77-blank-reply-stuck-repro.png`.

Low severity, but it is reachable by a fat thumb on a phone keyboard and it costs the person the feature on that notification.

## What held

1. **Box is there.** Backgrounded from the chat list, message arrived, notification `rig-A: tess` with a Reply action. Worth knowing for whoever walks this next: if the app is backgrounded while the *chat itself* is on screen, no notification is posted at all — the first attempt looked like a failure and was not one.
2. **Reply with no screen.** `on my way` typed into the box and sent: no app window at any point (top resumed activity stayed the launcher), the reply appeared in the thread under "You", the second member had it. Opening the app afterwards: the chat still showed unread 1 and the reply was in the timeline as my own message. `Sending…` still not observed — what shows is the spinner in the box, now six replies across three runs.
4. **App swiped away.** Staircase swiped off recents (confirmed gone from the recents list), notification stayed, `after swipe` sent from it and arrived.
5. **Process killed.** Delivery switched to Periodic first, `am kill`, `pidof tools.relay.staircase.debug` printed nothing, then replied: `cold reply two` went out and the process came back as a new pid. Instant re-enabled afterwards.
5b. Under Instant the process survives `am kill` — pid 7540 before and 7540 after, as expected while the foreground service holds it.
7. **Two chats at once.** Both notifications up, `alpha` to one and `bravo` to the other: each in its own thread, each in its own chat only, confirmed on the second member's client as well as on the phone.
10. **Mentions only.** Alerts set to "Only mentions", a real mention arrived as `rig-A · mentioned you`, the Reply box was on it, and the reply went out with no screen. Setting put back to All messages.
11. Smoke: launch, open a group, send from the composer — fine throughout.

Steps 3 and 8 not walked, as the run request set out. Step 9 is not walkable here.