Connect token passed via iframe query string instead of a less-exposed channel

## Where

`packages/sdk/src/browser/index.ts`, `BrowserClient.createIframe()`:

```ts
const token = opts.token || (await this.token());
const qp = new URLSearchParams({ token });
...
iframe.src = `${this.iframeURL}?${qp.toString()}`;
```

## Issue

The Connect token (which authorizes account-connection actions for the given `externalUserId`) is placed in clear in the query string of the iframe URL (`.../_static/connect.html?token=...`), rather than a channel with less server-visible exposure (URL fragment, or delivered via `postMessage` after the iframe loads).

A token in a query string can end up in browser history, be visible to any extension with tab-URL access, or leak to a third party via the `Referer` header if `connect.html` subsequently redirects to the target OAuth provider without a strict `Referrer-Policy`.

**Mitigating factor already in the code:** the comment at the `refreshToken()` call site indicates the token is single-use ("token expires once it's used to create a connected account"), which limits the exposure window.

## Why an issue and not a PR

`connect.html` isn't part of this repo (not present in `public/` or elsewhere under `packages/sdk`), so I can't confirm whether it currently reads the token from `location.search` only, or could be updated to also accept it from `location.hash` / a post-load `postMessage`. Changing the SDK's transport alone, without knowing how `connect.html` parses it, risks silently breaking the Connect flow for every integrator on the next SDK version. Flagging this as an issue so whoever owns `connect.html` can coordinate a fix across both sides -- happy to submit the SDK-side PR once the target format is confirmed.