Custom connector favicon lookup incorrectly resolves to public suffix (e.g. "co.za") instead of full hostname

### What happened?

The connector displays the favicon for the bare public suffix domain (`co.za`), which resolves to an unrelated third party's icon (the domain registry operator), not anything related to my server or organisation.

### What did you expect to happen?

The favicon lookup should use the correctly resolved registrable domain (e.g. `example.co.za`), not the public suffix itself (`co.za`).

### Steps to reproduce

1. Add a custom connector (Customize > Connectors > Add > Custom) whose MCP server URL's hostname ends in a second-level public suffix, e.g. `mcp.example.co.za`.
2. View the connector in the Connectors list.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Custom one built on Quarkus MCP

### Error messages or logs

```shell

```

### Additional context

When a custom MCP connector has no explicit icon, Claude falls back to fetching a favicon via `https://www.google.com/s2/favicons?domain=&sz=64`. For connectors whose server URL sits under a second-level public suffix (e.g. `.co.za`, `.co.uk`, `.com.au`), the domain-extraction logic appears to naively take the last two dot-separated labels of the hostname, rather than using a public suffix list (PSL) to correctly determine the registrable domain.

This causes the favicon lookup to be performed against the bare public suffix (e.g. `co.za`) rather than the connector's actual domain, returning an unrelated organisation's favicon (in my case, what appears to be ZA Central Registry's icon, since ZACR administers `.co.za`).

**Suggested fix**
Use a public suffix list (e.g. the Mozilla PSL, `publicsuffix.org`) when extracting the registrable domain from a connector's server URL for favicon lookup purposes, instead of a fixed "last two labels" heuristic. This affects any connector hosted under a ccSLD such as `.co.za`, `.co.uk`, `.com.au`, `.co.nz`, `.org.uk`, etc.

**Additional context**
This is distinct from issue #152 (no support for server-provided `icons` metadata) — even once that's resolved, this PSL parsing bug would still misfire as a fallback path for any connector without explicit icon metadata on a ccSLD domain.