feat: add the inbox to the mobile app

[leynier]

Summary

Mobile UI for the inbox over the paired-phone connection. The phone uses only the inbox verbs on its allowlist, and refreshes on inboxChanged.

• Feature detection: the inboxV1 capability, read from mobile.hello. aleraMobileProtocolVersion is not bumped.
• Inbox card: shown on the host dashboard when the host supports the inbox. It opens a thread list with filters, unread badges and Purge with confirmation.
• Thread screen: marks replies read on open, shows origin, target, delivery mode and expiry hints, and offers Cancel Question and a follow-up composer.
• Composer: picks a running agent grouped by workspace and asks from ext:user, the same inbox the desktop uses.
• Ask Agent: a new item in the workspace menu opens the composer with the open terminal preselected when it is an agent.
• Push: the inboxReply push kind opens the thread and never a terminal, under the existing attention preference. An older app treats it as unknown.

Stacked on the desktop PR.

Validation

• New tests: inbox_domain_test, inbox_screens_test, inbox_dashboard_card_test (17 tests) and a fake inbox client.
• flutter analyze reports no issues, and the full mobile flutter test passes (901 tests, 4 skipped).
• build_runner and EOF normalization were run, and the max-lines ratchet and git diff --check pass.

Risk

routePushIntent for inboxReply and the Ask Agent menu item have no widget test; push parsing is tested. Not yet run against a paired phone.

[pullfrog]

Important

The paste banner agents are told to run is not portable, and status filters only search one page of threads.

Reviewed changes

Reviewed the inbox stack on feat/inbox-mobile: persistence, host verbs, CLI, desktop page, and the mobile screens, against d1d183b67.

• Store — Questions from ext: addresses are orchestration messages, with expiry, cancellation, a pending cap, and a revision trigger.
• Host verbs — inbox.* is capability-gated (inboxV1, no protocol bump), allowlisted for phones except inbox.wait, and announced with inboxChanged.
• Delivery and push — Idle agents get a paste banner. Replies correlate on reply_to_id. inboxReply pushes ids only, never the reply text or a terminal.
• Desktop and mobile UI — Both ask from ext:user, list threads, and follow up. The phone feature-detects inboxV1 and opens the thread from the push.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using grok-4.7 ｜ 𝕏}

[pullfrog]

ℹ️ No critical issues. One suggestion on Load More.

Reviewed changes

Reviewed the mobile inbox delta on f41c7a7 since d1d183b67. The branch is now stacked on feat/inbox-desktop, so this diff is the phone UI only.

• Paging — The list sends the active inbox and status to the runtime and appends further pages with Load More. A change or a new filter starts again at the first page.
• Read acknowledgement — Opening a thread no longer marks replies read. The phone calls inbox.markRead only while that screen is current and the app is resumed, once per revision.
• Follow-ups — A follow-up omits inbox, so a CLI thread such as ext:ci keeps its own address. A new question still asks from ext:user.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using grok-4.7 ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes

Reviewed the mobile inbox delta on 0cd515e8 since f41c7a76. The branch was rebased onto the current desktop inbox branch. The phone patch is otherwise the same, plus Load More error handling.

• Rebased — Restacked the phone inbox on the current desktop branch. The mobile patch from the last review is unchanged aside from the list button.
• Load More — A failed next page is caught in the list button and shown as a SnackBar, so it no longer reaches the zone handler. The threads already loaded stay on screen, and the widget test fails the request then retries.

  ^{｜ View workflow run ｜ Using grok-4.7 ｜ 𝕏}