First-run deadlock: profile save 404s because it requires community membership, but setup asks for the profile first

### Summary

On a fresh identity, the first-run setup flow prompts for a profile (display name + photo) **before** the user has joined any community. Saving the profile returns `404` from the relay, and the image upload errors. Because the user can't get past this step, the natural conclusion is that the invite link they were sent is broken.

The underlying chicken-and-egg: profile writes appear to require a relay the user belongs to, but first-run ordering puts "set up your profile" ahead of "join a community."

### Steps to reproduce

- Fresh install; create a new identity.
- Attempt the profile step before accepting any invite.
- Save → relay returns `404`; image upload errors.

### What a member worked out independently

One of our members escaped it by **creating his own community** — which made him the owner of a relay, and therefore a member of one — completing the profile there, and only *then* clicking our invite link, which worked immediately. That strongly suggests the gate is "a profile write requires relay membership."

### Impact

This was the single largest drop-off we observed on launch day (14-member community, self-hosted). Corroborating signal: four of our members have no `display_name`, which is what you'd expect from people who hit this wall and abandoned the step.

### Suggested fix

Allow the profile step to be skipped or deferred until after a community is joined, or make the error state explain that a community must be joined first — rather than failing with a bare `404` that reads to the user as "the invite is broken."

### Environment

Self-hosted `deploy/compose` derivative, `ghcr.io/block/buzz:main`, relay behind Caddy with valid TLS; desktop app + iOS app. Community launched July 2026, 14 members.

_Note on a possibly-separate issue:_ the profile **image** upload error may be distinct (media goes to MinIO/blossom); I have not yet confirmed our MinIO is publicly reachable from outside the host, so I'm not asserting the image-upload failure is upstream. The **profile-save `404`** on a non-member identity is the reproducible part.