Mobile-first community onboarding needs an admin-safe channel-access path after an invite

## Problem

Buzz supports private communities, but the current mobile-first member journey is incomplete for a real organization.

A person can install the iOS app, accept an invite, and obtain a Nostr identity on the phone. However, community membership and channel membership are separate. A newly admitted employee can end up connected to the community yet see no usable channels, while the community owner must resort to raw public keys and manual, per-channel operations.

That is not an acceptable onboarding flow for a workforce that uses phones rather than computers.

This issue intentionally does **not** request that every invited person see every channel. Private channels, leadership channels, support channels, and agent channels must remain private.

## Desired product flow

1. An owner/admin creates a community invite.
2. A mobile user opens it, joins, and completes their own profile. See #3356 for the missing mobile profile editor.
3. The owner/admin can define a small set of **default / onboarding channels** (or an access bundle) for ordinary members.
4. On accepting the invite, the member is added only to those explicitly configured channels.
5. The mobile client shows a clear completion state: community joined, channels available, or a specific error/action if access is still pending.

## Why this matters

This is the normal deployment shape for a phone-first organization:

- employees should not need a desktop app just to appear with a name or receive initial channels;
- administrators must not handle private keys or impersonate an employee's identity;
- invitations must not accidentally expose management, HR, support, operational, or agent channels;
- users should not be asked to copy a pubkey merely to access the first channels.

## Proposed scope

- An owner/admin-configurable **default member channel set** or named access bundle.
- Invite acceptance atomically (or reliably/retryably) adds the member to that set.
- A visible mobile onboarding result, including whether the user has zero channels by policy or because provisioning failed.
- Safe idempotency: re-opening an invite or retrying a network failure must not duplicate memberships or create extra identities.
- An administrator remains able to add/remove additional private channels later.
- The member's profile remains self-owned and signed on-device; no admin profile-writing capability is introduced.

## Non-goals

- Making all community channels visible by default.
- Giving invitees admin or owner permissions.
- Letting an agent infer an employee's business role from a Nostr key alone.
- Moving private keys off the user's phone.
- Replacing custom organizational onboarding or HR verification. Those systems may still decide which bundle an employee receives.

## Acceptance criteria

- [ ] On iOS, a person joining by invite can complete or later edit their own display name without a desktop client (#3356).
- [ ] An owner/admin can configure which channels are granted to a standard invited member.
- [ ] A successful invite grants only that configured set, never every channel.
- [ ] A mobile user can see the granted channels immediately after join or receives a precise retryable failure state.
- [ ] A member with no granted channels sees an intentional, understandable empty state rather than an indistinguishable broken connection.
- [ ] Retrying the onboarding path is idempotent.
- [ ] Existing private-channel policies and owner/admin roles are preserved.
- [ ] No private key, token, or employee identity data is exposed in the process.

## Related

- #3356 — mobile users cannot set a display name / publish their own kind-0 profile.
- #3544 — first-run profile save can deadlock before community membership exists.

## Environment

Observed with the current iOS Buzz app v0.7.0 against a hosted/private Buzz community in August 2026.