Support creating a session from a non-GitHub issue URL via a connected MCP server

## Problem

The "Create session from..." entry point only understands github.com pull request and issue links. If you paste an issue URL from another tracker (Azure DevOps, Jira, GitLab, a self-hosted GitHub, and so on), nothing useful happens, even when you already have an MCP server connected for that tool.

## Idea

When the pasted URL is not a github.com link, match its host against the MCP servers the user already has enabled. If one of them appears to serve that host, offer a "Create from " action, grouped under that server's name. Selecting it starts a new session whose first instruction is to fetch the item through that MCP server, read its title and description, and begin work.

Matching is fuzzy and string-based: both the host and the server's name and URL are split into lowercased tokens, short tokens are dropped, and a server is considered a match when one of its tokens and one of the host's tokens contain each other, so the URL lines up with the right server without any hardcoded host list.

### Example

Say you paste:

```
https://dev.azure.com/myorg/myproject/_workitems/edit/1602/
```

and you have an MCP server named `azure-devops` enabled. The host `dev.azure.com` becomes the tokens `azure` (the short pieces `dev` and `com` are dropped). The server `azure-devops` becomes `azure` and `devops`. Both sides share `azure`, so the two match and you get a "Create from dev.azure.com" action under the `azure-devops` group. The same shape works for a `jira` server against a `*.atlassian.net` host, or a `gitlab` server against a GitLab host.

This reuses the existing MCP connection and auth. No new credentials, no tracker-specific integrations to maintain.

## Why this is nice

- One paste box handles GitHub and everything an MCP server can reach.
- If the URL matches nothing, the experience is identical to today, so it stays out of the way until it is useful.
- Adding support for a new tracker means connecting its MCP server, not writing new code.

## Open questions

- How to pick when more than one connected server could plausibly serve the host.
- Whether self-hosted GitHub should go through this path or the native GitHub one.

Start at the existing "Create session from..." entry point and trace how GitHub issue and pull request URLs are recognized, then inspect how enabled MCP servers expose their names and URLs. Define the host-token matching and server grouping behavior, including multiple matches and self-hosted GitHub. Done means supported non-GitHub URLs offer the appropriate action and unmatched URLs retain today's behavior.

Written by the indexing model from the issue text.