fix(desktop): fetch join policies through native networking

[johnmatthewtennant]

Context

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.

Summary

This bug fix fetches join policies through Tauri's native networking layer for direct URL joins. Invite-code discovery, policy acceptance, and signed invite claims remain on the WebView path so those operations can migrate together later.

Changes

• Uses native networking for Add Community and first-community direct URL join-policy requests.
• Validates relay schemes, rejects URLs containing credentials, and refuses redirects.
• Bounds declared and chunked native responses before JSON parsing.
• Preserves existing 404, non-success status, malformed JSON, and absent-policy behavior.
• Requires every join-policy caller to 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

Reviewer-reproducible examples

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

Red: main

From a clean checkout of main:

. ./bin/activate-hermit
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:

. ./bin/activate-hermit
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 and sidebar Playwright tests.
• Full just ci and pre-push suites.
• Builderbot, Kalvin, and minimize-diff review fanout found no actionable issues after the final rebase.

[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.

[wpfleger96]

🤖 Rechecked the review fixes at exact head 29b65c86e5a3013641be51277d812081a64c7422. The native response now has declared-length and streamed byte caps with both oversize cases tested; transport is required and explicit at every caller; the native TypeScript contract test is in place; stale route mocks are gone; the description is scoped to direct URL joins; and the remaining invite-path CORS work is linked as #2872. I don’t see any remaining blocker.