Show server-provided icons for connectors that aren't connected yet (SEP-2127 Server Cards)

Related to #152, but a different surface and a different mechanism, so filing separately.

## The problem

The connector list is a selection surface. It mixes connected and not-yet-connected connectors, and the user picks from it — which connector to open, which one to connect. An icon that only appears after connecting arrives after the choice has already been made.

Right now every custom connector in that list renders as a letter tile regardless of state, and #152 covers only half of the fix: `serverInfo.icons` travels in the `initialize` response, which for an OAuth-protected server is only reachable once authorization has completed. For a connector the user hasn't connected yet, there is no mechanism at all for the server to identify itself visually.

What fills the gap today is `google.com/s2/favicons?domain=` (documented by @aishadvitya and @awhitford in #152). That has two problems beyond simply not working for un-indexed domains:

- It attests to whoever controls the apex domain, not to the MCP server being listed.
- It collapses for anyone hosting multiple servers under one apex domain. Even if the lookup succeeded, every connector under that apex would resolve to the same tile — no more distinguishable than the letters they show now.

## The mechanism already exists

[SEP-2127 (Server Cards)](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2127) — marked Final and awaiting merge — defines exactly the document needed here: a static, unauthenticated metadata document at the reserved location `GET /server-card`, carrying

```ts
icons?: Icon[]; // same Icon shape as SEP-973
title?: string;
websiteUrl?: string;
repository?: Repository;
```

(Schema: [`schema.ts`](https://github.com/modelcontextprotocol/experimental-ext-server-card/blob/main/schema.ts) in the [experimental-ext-server-card](https://github.com/modelcontextprotocol/experimental-ext-server-card) repository, which SEP-2127 designates as the normative source. The `Icon` type is the one from [SEP-973](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1040), already in the spec as `Implementation.icons` since `2025-11-25`.)

It is explicitly designed for pre-connection discovery, so it is fetchable at the moment the connector list is rendered — including for connectors the user has never authorized.

One note on how a client finds the card. The extension's [discovery flow](https://github.com/modelcontextprotocol/experimental-ext-server-card/blob/main/docs/discovery.md) is catalog-first: a client fetches `/.well-known/ai-catalog.json` for a domain and follows the `url` each entry gives it, so it never has to guess a card's location. That flow is aimed at domain-level discovery, which isn't the situation here — a custom connector is added by pasting an MCP endpoint URL, and there may be no catalog anywhere in the picture.

For that case the reserved default is what makes this workable: the spec reserves `GET /server-card` precisely so a server has a predictable place to put its card. A connector added as `https://example.com/mcp` yields `https://example.com/mcp/server-card` by appending the reserved suffix — no catalog lookup and no guessing, since the location is reserved by the spec. Requesting that URL with `Accept: application/mcp-server-card+json` when a custom connector is added would cover connectors that no catalog lists.

## Request

Read `icons` from the Server Card when rendering connectors that are not connected, in the connector list and the add-connector dialog, in place of the Google favicon lookup.

Together with #152 this covers the whole list: Server Card icons before connecting, `serverInfo.icons` after.

## On trust

[SEP-2127](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2127) states that a card's declarations are advisory and must not be treated as authoritative for security decisions. That framing is right and worth preserving in the UI: a self-asserted icon can't prove a server is genuine.

It is still a meaningful improvement over the status quo. When the user is deciding which server to hand an OAuth token to, the UI currently shows a name and a URL — both entirely attacker-supplied for a server being added for the first time — and a favicon belonging to the apex domain. A server-asserted mark at least lets someone notice when the familiar one is missing or wrong.