[simonhamp]

Adds muting and blocking to the app, and a screen to undo them, the way the web does it.

API PR: simonhamp/devnull.com#1, stacked on nunomaduro/dev-null.sh#130. The app needs it for the new endpoints, and for the blocked user that now comes with user_blocked.

What changed

• Someone else's profile has a ⋯ in the nav bar that opens a native menu, like the web's safety menu: Mute or Unmute @them, and Block @them in red. A profile you blocked offers only Unblock, and one that blocked you has no menu, as on the web.
• Each item asks first with Dialog::alert. Block uses the web's Block dialog word for word. Mute uses the web's own line for it ("You won't see their commits or hear from them, and they won't know."), and Unblock what the web's Safety page says ("Unblocking doesn't bring back follows."). The web has no wording for Unmute beyond the label, so that alert is just "Unmute @them?".
• After you confirm, the profile changes straight away and goes back if devnull says no, like Follow. Blocking shows the existing blocked page. That page now has Unblock, as the web's does, and "Muted and blocked people" opens the new screen in the app instead of the web.
• New Muted and blocked screen (Safety, at {tab}/safety), from a Safety section on the Account screen. It lists both groups with the web's headings and empty states, Unmute and Unblock beside each person, and Show more when there's another page. It opens on what was kept last time and refreshes behind it, like the other screens.
• Mutes and blocks patch the kept answers they change: the profile's is_muting, the two lists, and the kept logs, which drop the person's commits. A block also forgets their kept profile and commits, and takes the ended follows off your counts. The Log takes their commits out of what it's showing when you come back to it, which Trending and pages further down need since a fresh first page doesn't touch them.
• Three Lucide icons the web's menu draws: volume-x, volume-2 and ban.

What to look at

• Alert ids carry the username (mute:ada), so a button press only reaches the profile that asked.
• NativePHP keeps one #[On] listener per event on a screen, so Profile's onAlertButton() would have replaced the one ShowsCommits uses for Delete commit. The trait's handling now lives in answerDeleteAlert(), which Profile's handler calls before its own alerts. CommitMenuTest's "deletes your own commit from your profile" fails without that call.
• The log's "hidden lately" list is read once and then forgotten. That way a mute undone on the web can't keep hiding someone's commits on the phone.
• The blocked page's own Unblock button doesn't ask first, like the web's. The menu's Unblock does, as asked.

Verified

• php artisan test after rebasing onto main: 769 passed, CommitMenuTest and SavedTest included, with new tests for the menu, each confirmation, the rollbacks, the blocked page, the new screen, the Account entry and the cache patches.
• On an iPhone 17 Pro simulator against a local devnull serving the API PR: muted a test user (mb-ada), saw Muted on her profile and her commit leave the log, blocked another (mb-grace) and saw the blocked page and her commit leave the log, then undid both from Muted and blocked, opened from Account. mb-ada's commit came back. mb-grace's didn't, since the block ended the follows and unblocking doesn't restore them, as on the web.

Screenshots, from the orphan branch mute-block-screenshots (delete it after merge):

Menu	Mute confirm	Muted	Log after mute

Block confirm	Blocked page	Blocked menu	Muted and blocked

Account	After Unmute	After Unblock	Log after undoing

After rebasing onto main, on a fresh simulator: deleting your own commit from the Log and from your profile, then mute, block, the blocked page and undoing both from Muted and blocked. The lists also show a mute and a block another session made on the shared dev account.

Delete from the Log	Gone, with the toast	Mute confirm	Muted

Blocked page	Muted and blocked	After undoing	Delete from your profile

🤖 Generated with Claude Code