Add mobile community invites - #5641

🤖 Native Pixel snapshots from the isolated review build.

Invite page

Create, share, or copy a configurable community invite link, or enter an npub directly.

Direct npub invite

A valid npub resolves to one compact identity row with Invite and owner-only role selection.

Expiry options

Link settings use the established Buzz single-choice sheet treatment.

🤖 Post-merge review notes from an agent review drive on be4fb7a18135f276f32d2b5f3ab49ddac4be8695, the commit that landed. Three seats reviewed this: correctness and test strength, a red-team pass on the invite lifecycle and the widget extraction, and integration. We found no blocker. The gate holds, the escalation path is closed on both the client and the relay, and the suite goes 1261 to 1277 with flutter analyze clean.

These are non-blocking follow-ups. They now live on main, so treat them as repo-level items rather than a charge against this PR. Nothing here needs a revert.

1. The invite directory surface has no reader in the UI. communityInviteDirectoryProvider and communityInviteDirectorySearchProvider, plus the paged kind:0 query and the membership-snapshot fallback inside them, are about 90 lines that nothing in lib/ reads. The only lib/ reference is the search provider delegating to the directory provider. invite_create_page.dart and its two part files read communityInviteActionsProvider and communityInviteProfileProvider only. CommunityInviteDirectoryUser.initial and .secondaryLabel have no reader anywhere, including tests, and .label is read only by the sort inside the dead directory provider itself. Deleting both providers keeps analyze lib/ clean; the suite only goes red because three overrides in invite_create_page_test.dart name the now-undefined providers, which means the tests configure providers the UI never reads. Either wire up the directory list or drop it, so the tests stop implying coverage of a surface that does not render.

2. The NIP-29 role index cannot fail a test today. communityMembershipFromEvents accepts both ["member", pubkey, role] and ["p", pubkey, relay, role], and the role sits at a different index per form. Changing the p-form index from 3 to 2, which reads the relay URL as the role, keeps the suite green. The reason is that the one legacy-form row in the test carries role member, which is also the default, so the wrong read still produces the right answer. The shipped index is correct and matches desktop relayMembers.ts construct for construct. Only the guard is untested. One legacy-form row with admin closes it, and that arm does kill the mutant.

3. Opening the invite page mints a live invite code, and every option change mints another. _InviteLinkSection.generate runs from a useEffect keyed on TTL and max uses, so one visit plus two option changes creates three distinct live codes. The earlier codes are not revoked: mint_relay_invite inserts a new row, claim_relay_invite keeps accepting each row until its own expiry or max-uses is exhausted, there is no per-community cap on outstanding codes, and reap_expired_relay_invites only removes rows after expiry plus the retention window. This is desktop parity, not a mobile regression. Desktop InviteLinkSection mints on open and on every settings change too, and its unchanged E2E explicitly expects a mint on open, a remint after a selection change, and another mint after reopen. Raising it as a product question rather than a defect: bearer invite codes abandoned by navigation alone stay claimable, and it may be worth minting lazily on first share or capping outstanding codes.

4. mintInvite decodes the body before it checks the status. jsonDecode(response.body) runs ahead of the statusCode range check, so a non-JSON error response, for example an HTML proxy or gateway page on a 500, throws "Relay returned an invalid invite response" and the status never reaches the user. A JSON error body still surfaces its relay message correctly. Checking the status first would make the failure diagnosable.

5. Raw exception text reaches the user. _inviteErrorMessage is error.toString().replaceFirst('Exception: ', ''), which strips only that one prefix. The StateError thrown by _ensureCommunityActive renders verbatim as "Bad state: Invite cancelled because the active community changed".

6. Two small drift items. Neither anchored hex pattern has a test for its anchors, so if the ^ and $ were ever lost, a 70-character paste containing 64 hex characters would be accepted with no test failing. Separately, _searchIdleTextSize in search_page.dart and buzzSearchIdleTextSize in BuzzSearchField are now two independent constants feeding the same layout. Both are 15 today, so the idle field height and the hint height still agree, but the height math spans both files and only one of them is the widget's own.

For the record, we confirmed the things most likely to be wrong here and they were right. A plain member is denied on both the settings row and the page body. No client path submits role=admin as an admin: with the Role row forced visible and Admin selected, the submit guard still forces member, and the relay rejects it independently anyway. Unmounting mid-flight during a link mint or a membership submit raises no disposed-state exception, so the earlier bot comment on that hazard is genuinely resolved at this commit. BuzzSearchField and BuzzActionTile are behavior-identical to the code they replaced, down to the "Opening direct message" loading label, and AppListCard's new dividerIndent leaves every existing caller on the old value. The role gate failing open on a lookup error, with "Could not check permissions" and a Retry, reads as deliberate and has a test.

One merge-order note: this merge put #5401 into a conflicting state. The single conflict is in user_profile_sheet.dart, where this PR removed the private _ProfileActionTile and repointed both call sites at the shared BuzzActionTile while #5401 keeps _ProfileActionTile for the animated-avatar work.