MCP server tools unavailable on one shot prompts

### Short summary

MCP server tools unavailable on first prompt of new session; require follow-up message to appear

### Affected version or release

1.0.71-2

### Installation context

Slack MCP server configured via ~/.copilot/mcp-config.json (type: http, url: https://mcp.slack.com/mcp, OAuth public client). Likely affects any remote/HTTP MCP server, observed specifically with Slack MCP.

### What happened?

On the first user prompt in a brand-new session, tools contributed by a correctly configured remote MCP server (Slack MCP) were completely absent from the assistant's available tool list. Running extensions_manage(list) / extensions_reload also reported "0 extensions running / No extensions found," which is misleading since this MCP server isn't part of the .github/extensions system, so there was no way to detect or force-refresh the connection from within the turn.

Only after the user sent a second, unrelated follow-up prompt did a "tools_changed_notice" system event fire, exposing the Slack-MCP-* tools (slack_send_message, slack_read_channel, etc.). The assistant had no mechanism to trigger this itself on turn one.

Separately, later in the same session, an unprompted "Tools no longer available: Slack-MCP-slack_send_message" notice appeared with no user action taken, showing tools can also silently disappear mid-session.

### Steps to reproduce

1. Configure a remote/HTTP MCP server (e.g., Slack MCP) with OAuth in mcp-config.json.
2. Start a brand-new chat session.
3. On the very first prompt, ask the assistant to use a tool from that MCP server.
4. Observe the tool is missing from the available tool list (extensions list also shows 0 running).
5. Send any second, even unrelated, follow-up prompt.
6. Observe a "tools_changed_notice" fires and the MCP tools become available.

### Expected behavior

Tools from a correctly configured MCP server should be available on the first prompt of a session without requiring a throwaway follow-up message to "wake up" the tool list. If a connection/handshake delay is unavoidable, the assistant/runtime should detect and wait or retry within the same turn instead of requiring user intervention.

### Additional context

- ~/.copilot/mcp-config.json:
{
"mcpServers": {
"Slack MCP": {
"tools": ["*"],
"type": "http",
"url": "https://mcp.slack.com/mcp",
"oauthClientId": "",
"oauthPublicClient": true
}
}
}
- extensions_manage(list) and extensions_reload both reported 0 extensions before the Slack tools appeared - this API doesn't seem to surface remote MCP server status.
- Tool availability also churned later in-session (tool silently removed), suggesting a broader MCP connection lifecycle issue beyond just cold start.
- Model: All available models (tested with GPT 5.6 Luna, GPT 5.6 Tera, Haiku 4.5, Sonnet 5), GitHub Copilot CLI/App v1.0.71-2, Windows

Start by reproducing the first-turn failure with the Slack MCP entry in ~/.copilot/mcp-config.json, then compare extensions_manage(list), extensions_reload, and the second-prompt tools_changed_notice. Trace the MCP connection lifecycle around initial discovery and later tool removal; it is done when configured remote-server tools are available on the first prompt and remain available without requiring a follow-up.

Vom Indexierungsmodell aus dem Issue-Text verfasst.