explore(desktop): discovery-first onboarding landing (Discord-style)

[thomaspblock]

Summary

Exploration: discovery-first onboarding (Discord-style). On first open, the app lands on a community discovery screen instead of the agent-setup corridor.

• New discover page prepended to MachineOnboardingPage — now the initial page (identity-lost still routes to key import; initialPage overrides preserved).
• DiscoveryLanding.tsx: featured community cards with one-click Join, plus "advanced setup" (old corridor) and "use an existing key" (key import) escape hatches.
• One-click join defers all agent setup: identity is persisted silently via getIdentity(), machine onboarding completes, and a first-community community-onboarding transaction connects to the chosen relay. Backup / harness / config become post-join concerns.
• featuredCommunities.ts: static featured-community list (incl. Buzz HQ) — a relay-served directory is a natural follow-up.
• Identity page gains a Back button returning to discover.
• Fix: OnboardingFooter renders the footer slot before the Back button so Back stays clickable above wide docked CTA groups (found via the e2e spec — the identity help trigger's pointer-events-auto group intercepted clicks).
• e2e screenshot spec discovery-landing-shot.spec.ts added to the smoke project.

Verification

• tsc clean, biome + repo checks ALL_GREEN
• Full unit suite: 4954/4954 pass
• e2e spec passes; screenshots posted in a comment below (camo blocks relay media URLs)

Links

• Track 2 issue: buzz://issue?id=4215da4b35ff9576b97b101e03f5b50140e38a396793f0517b4f8c27d6f43e68&owner=011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd (Onboarding project)
• Originating thread: buzz://message?channel=661c64d4-4a78-4562-87ac-452cbf89a0c4&id=d909d4087cf780e3159bd727005909cc41a2cac22f3c9bd3d6a8f42b8130c606

[thomaspblock]

Screenshots

[themiguelamador]

Two blockers remain in the discovery-first join path:

• communityOnboarding.start() deliberately returns false when a different onboarding transaction is already pending. quickJoinCommunity ignores that result and still calls complete(identity.pubkey). An acknowledged deep-link transaction therefore lets the user click a featured card, completes machine onboarding, and then connects the other pending community instead of the one shown.
• Three cards are marked openJoin: true even though their relay hosts do not resolve (agents.buzz.builderlab.xyz, nostr.buzz.builderlab.xyz, and nomads.buzz.builderlab.xyz). DiscoveryLanding never consults openJoin, so all three dead endpoints are advertised as working one-click joins.

I fixed both in Complear:review/pr-5976-fix at 01bc5be66f5b4ed54380c7655aa7794bc8f779b7: rejected transaction starts now leave machine onboarding incomplete and show an actionable error; unavailable entries render disabled “Coming soon” buttons; and the E2E spec covers both the disabled catalog entries and the pending-transaction collision.

Verification:

• fresh pnpm build:e2e — passed
• focused discovery Playwright suite — 2 passed
• screenshot SHA-256 check — all 3 states distinct
• focused Biome — clean
• pnpm exec tsc --noEmit — passed
• pnpm test — 4,954 passed