Model contradicts its own runtime behavior — claims no HTTP MCP support while actively using it

### Describe the bug

The model (Claude Opus 4.6 via Copilot CLI v1.0.41) makes 50+ successful native HTTP MCP tool calls during a session, then when asked to create a comparison table of AI clients, incorrectly classifies its own runtime as "❌ does not support HTTP MCP — needs stdio proxy". This directly contradicts what it is doing in the same session.

### Affected version

1.0.41

### Steps to reproduce the behavior

1. Connect Claude Opus 4.6 to an MCP server via HTTP transport (Streamable HTTP)
2. Successfully use MCP tools (li_h, qu_i, fuz_s, etc.) — model calls them natively throughout the session
3. Ask the model to create a comparison table of AI clients and their MCP transport support
4. Model classifies its own runtime (Copilot CLI) as "❌ stdio only — needs proxy" despite actively using HTTP MCP tools in the same conversation

Actual Result: Model outputs Copilot CLI (мы) | ❌ | — | — | ✅ Через stdio-proxy — claiming it does NOT support HTTP transport and requires a proxy, while simultaneously using HTTP transport without a proxy.

Impact: Provides incorrect technical guidance to the user. User had to manually correct the model. This is a self-contradiction — the model's declarative knowledge conflicts with its procedural behavior in the same context window.

### Expected behavior

_No response_

### Additional context

Additional Context:
- Sub agents in the session were called and used the proxy to be able to call the mcp tools natively! Looks like this was impact the table.
- The model had made 50+ successful native HTTP MCP tool calls in the same session before producing the incorrect table
- When confronted, the model immediately acknowledged the error and corrected it
- This suggests the model relies on stale training data about "Copilot CLI capabilities" rather than introspecting its actual runtime environment