Blueprint import: binding picker ignores resourceUrl and preselects an arbitrary same-type connection

## Description

When importing a `.gadget` blueprint whose bindings are MCP gatekeeper bindings with distinct `resourceUrl`s, the binding-assignment UI preselects an existing MCP account of the same *vendor type* without matching the binding's `resourceUrl` — and the outer assignment screen displays the blueprint's **suggested** URL as if it were the selection, so the mismatch is invisible until Create fails (or, worse, doesn't).

Observed on our self-hosted deployment (starter pin `3d211477`, cloudflare-os `6478a144`); still reproduces for us as of 2026-08-30, and the picker components look unchanged on current `main`.

## Steps observed

**Reproduction A — two same-type bindings, wrong one preselected:**

1. Blueprint with two MCP bindings: `LINEAR` (`resourceUrl: https://mcp.linear.app/mcp`) and `GITLAB` (`resourceUrl: https://gitlab.com/api/v4/mcp`). Workspace has both accounts connected.
2. Import the blueprint. The outer screen showed the LINEAR row as "Ready — Using: https://mcp.linear.app/mcp", but the actual preselection was the **GitLab** account.
3. Create failed with: `This connection is for https://gitlab.com/api/v4/mcp, not https://mcp.linear.app/mcp`.
4. Workaround: open **Change** on every MCP binding and pick the account explicitly.

**Reproduction B — no matching account exists at all:**

1. Blueprint binding `BRAND_VOICE` with `resourceUrl: https://bv.inspekter.app/mcp`; no account for that endpoint exists in the workspace.
2. The outer screen presents the binding as correctly assigned (showing the blueprint's suggested URL).
3. Opening the binding's configuration dialog shows an unrelated same-type account (mcp.linear.app) already selected with a checkmark, with that account's 62 tools listed below.

So this doesn't look like a fuzzy match gone wrong: the picker appears to default to an arbitrary existing account of the vendor regardless of `resourceUrl`, and the summary renders the blueprint's suggestion rather than the actual selection.

## Expected behavior

- Preselect only an account whose endpoint matches the binding's `resourceUrl` (respecting `typeUrlPattern`); otherwise preselect nothing and prompt to connect.
- The outer assignment screen should render the *actual* selected account, not the blueprint's suggested URL.

## Impact

Silent cross-wiring of connections. With the "Create fails" guard (repro A) it costs a confusing error; if any code path saves without that guard (repro B's dialog offers "Save connection"), a gadget ends up calling a completely different MCP server than its blueprint declared — with whatever tools and approval tiering that account happens to have.

Start by reproducing the import in the binding-assignment UI with two same-type MCP accounts, then inspect the picker components and outer assignment screen. Compare the binding resourceUrl with the account selected in the configuration dialog and the URL rendered in the summary. Done means only an endpoint-matching account is preselected, unmatched bindings remain unselected, and the summary shows the actual selection.

Written by the indexing model from the issue text.