fix(desktop): defer the first-run profile write until membership exists

[Tr1ckyMag1ca1]

Fixes #3544.

Stacked on #4821 — review that one first. This branch is built on top of it, so the diff below includes #4821's commit (fix(desktop): recognize the membership gate's bodyless 404 in onboarding). The dependency is real: this imports the shared isRelayMembershipDeniedError that #4821 introduces. Base is main only because GitHub does not allow a fork branch as a cross-fork base. Review only the second commit here, and merge #4821 first — this rebases cleanly once it lands.

The deadlock

First-run setup asks for a display name and avatar before the user has joined any community. A kind:0 write requires relay membership, so the save is refused and setup dead-ends. Per #3544 this was the single largest drop-off on a live self-hosted community — corroborated there by four members left with no display_name, which is what you'd expect from people who hit the wall and gave up.

The key point: at that moment membership is unsatisfiable. The user has nothing to be a member of yet. Every affordance on the denied screen — retry, import a key, change community — assumes a community they are trying to get into. First-run users have none, so the refusal is terminal.

Note this is not fixed by deferring only the profile write: update_profile (desktop/src-tauri/src/commands/profile.rs) is a read-merge-write and calls query_relay first, so the gate rejects the read. #4821 covers recognizing that refusal; this PR covers surviving it.

Approach

Stop treating the refusal as terminal — park what the user typed and replay it once membership exists.

features/profile/pendingProfileSave.ts (new) mirrors the existing avatarProfileSync deferred-write pattern, with one deliberate difference: it persists to localStorage. Joining a community remounts the community-scoped React tree, and the user may quit and relaunch before joining, so in-memory state would not survive the gap. (Relaunch-then-reclick is exactly how one user escaped this in practice.)

Safety properties, each covered by a test:

• Identity-scoped. A different active pubkey discards the value rather than writing one user's profile under another's key.
• Keeps waiting when membership still is not established, or when no identity resolves yet.
• Drops on non-membership failure, so a malformed value cannot wedge every later boot with a permanent retry.
• Storage failures never propagate — losing a deferred value beats failing the step the user is trying to get past.

Flush point: the community-ready transition in useCommunityInit, the first moment the write can succeed. Failures there can never block readiness.

MembershipDenied gains an optional onContinueWithoutProfile — "Finish this after I join" — supplied only by first-run onboarding. The invite flow omits the prop and is visually unchanged.

OnboardingFlow: both membership-denied branches now route through one enterMembershipDenied helper that parks the draft, replacing duplicated inline handling.

Community-switching contract

resetPendingProfileSave() is registered in resetCommunityState() and documented in AGENTS.md, per the module-singleton rule. The persisted value deliberately survives the reset — it is keyed to an identity, not a community, and exists precisely to outlive the remount that joining causes. Only the in-memory instance is dropped.

Testing

• just desktop-ci — green (exit 0).
• 12 new unit tests in pendingProfileSave.test.mjs covering flush outcomes, identity mismatch (including case-insensitive comparison), deferral, discard-on-hard-failure, malformed/foreign storage contents, and throwing storage.

Not covered: the OnboardingFlow / MembershipDenied wiring has no component test — the repo tests this layer via Playwright, and a spec for "denied → continue → join → profile appears" needs a relay-backed fixture. Worth adding; flagging rather than silently skipping.

Follow-up, deliberately not in scope

The invite flow (CommunityOnboardingFlow) does not park its draft on denial. Its profile step runs after the community is applied, so the flush has already happened by then and parking would only pay off on a later community switch. Straightforward to add if reviewers want symmetry.