fix(desktop): fetch join policies through native networking

[johnmatthewtennant]

Summary

Adding an existing community by relay URL could fail with Community rejected: Load failed even when its WebSocket endpoint was reachable. The Add Community flow fetched /api/join-policy from the WebView, so a relay without a matching CORS allowance blocked the policy request before the app could join it.

This bug fix:

• Fetches join policies through Tauri's native networking layer for Add Community and first-community direct URL joins.
• Validates relay schemes, rejects URLs containing credentials, and refuses redirects.
• Bounds native policy responses before JSON parsing, including declared and chunked bodies.
• Preserves existing 404, non-success status, malformed JSON, and absent-policy behavior.
• Keeps invite-code discovery, policy acceptance, and signed invite claims on the WebView path so those operations migrate together later.
• Makes every join-policy caller choose its transport explicitly.

Public relays using Buzz's default permissive CORS configuration are not known to be affected.

Related issue

Related to #2872.

Testing

End-to-end red/green requires access to a relay with a restrictive CORS configuration and a Buzz identity authorized to join it.

Red: main

From a clean checkout of main:

just staging

In Buzz Desktop:

1. Add another community so the restrictive-CORS relay can be removed.
2. Remove that relay.
3. Open Add Community and enter the relay's WebSocket URL.
4. Select Add Community.

Observed result:

Community rejected: Load failed

Green: this PR

From a clean checkout of this branch:

just staging

Repeat the same steps above.

Observed result:

The community rejoins successfully.

Supporting checks:

• Six native join-policy tests, including oversized declared and chunked responses.
• Four TypeScript API tests, including the native command contract.
• E2E build and four focused onboarding/sidebar Playwright tests.
• Full desktop and Tauri pre-push test suites.

[bp2m6v4sp5-dev]

Submit

[wpfleger96]

🤖 hey @johnmatthewtennant — I like the direction here, native networking is clearly the right escape hatch for a CORS-restricted relay, and the redirect refusal + credential rejection are nice hardening on top. Two things I'd want changed before this goes in, plus a few smaller notes inline.

Blocking, both left as inline comments:

1. the native command buffers the whole response body from an arbitrary user-entered relay (response.json())
2. transport defaults to "webview" — the broken path is the default a new caller gets

Non-blocking notes:

desktop/src/shared/api/invites.test.mjs still only exercises the webview branch (every getJoinPolicy call in it omits the transport arg). Worth one native-transport case that pins the command name fetch_join_policy, the relayUrl arg shape, and the mapping — the two branches aren't symmetric (webview unwraps raw.policy, native returns the already-unwrapped policy), and right now nothing on the TS side locks that down.

The reported bug still reproduces for invite-URL joins against the same relay, since getJoinPolicy on the invite path, acceptJoinPolicy, and claimInvite all stay on webview fetch. I get why (the description says as much) — could you file a follow-up issue and link it here so the remaining half doesn't get lost?

Nothing here looks wrong to me on the parts I didn't comment on: 404/non-success/malformed-JSON semantics match the old flow, and I ran the URL builder against .. traversal, %2F-encoded segments, IPv6 hosts, uppercase schemes, and bare ws:///foo — all either rejected or normalized sanely.