fix(mobile): join starter channels after accepting invite

[brow]

What changed?

After a new mobile invite claim succeeds, Buzz now best-effort ensures membership in the same public starter channels as desktop:

• #general
• #welcome-everyone

Missing starters use desktop's deterministic per-relay IDs and exact public channel configuration, so concurrent mobile and desktop setup converges safely. Setup failures do not invalidate or retry an already successful invite claim, and failure for one starter does not block the other.

The success sheet offers Continue to #welcome-everyone when that channel is available. Mobile does not create the private Welcome channel because it cannot provision the desktop Welcome agents that make that channel useful.

This PR is stacked on #6145 because it deliberately reuses that PR's open-channel directory and join behavior. Once #6145 merges, this PR can be retargeted to main without changing its BUZZ-12 diff.

Fixes BUZZ-12.

How is it tested?

• Desktop/mobile deterministic starter-ID parity coverage.
• Existing-channel join and missing-channel creation coverage.
• Duplicate-create convergence and per-channel failure isolation coverage.
• Invite success remains successful when starter setup fails.
• Widget coverage for continuing directly into #welcome-everyone.
• Focused invite/deep-link tests: 23 passed.
• just mobile-check: passed.
• just mobile-test: 1,483 passed.
• Pre-push repository checks: passed.

[themiguelamador]

The recovery state is only held in InviteJoinState.claimCompleted. If Welcome setup fails and the sheet is dismissed (or the process restarts), the community remains persisted, but reopening the invite takes the existing-community shortcut and never calls recovery. That leaves the user permanently on the empty community path this PR is intended to repair unless they happened to keep the original sheet open. The recovery error also overflows the invite sheet at the standard widget-test viewport, and the post-claim action is misleadingly labeled “Join”.

I fixed these in commit 84bb79edb (branch review/pr-5915-fix): existing-community invite opens now switch identities and run the same idempotent Welcome recovery without generating keys or reclaiming membership; failures reopen a dedicated “Finish setting up” / “Retry setup” state; and the sheet scrolls when recovery copy exceeds the available height. Regression coverage proves a saved community can fail recovery, retry successfully, and make zero key-generation or claim requests, and exercises the rendered error state without overflow.

Verified with the focused invite-provider and deep-link widget suites, just mobile-check, all 1,403 mobile tests, and git diff --check. Per repository policy, I did not run Flutter build/run/clean/upgrade commands.