Chat ignores `toolSearchEnabled` in 3P mode while Cowork and Code honour it

## Summary

`toolSearchEnabled` is a workspace-level managed (MDM) setting, but it only takes effect on the Cowork and Code surfaces of the Claude Desktop app. The Chat surface in the same app, same account, same managed config ignores it and loads every connector's tool schemas inline on every turn. On accounts with a normal number of connectors enabled, Chat exhausts the context window after a single query and the stream dies with a "too much context" error.

Observed on Claude Desktop in third-party (3P) mode, signed in against a self-hosted gateway (custom inference base URL) rather than a claude.ai account. In 3P mode tool search is off by default, so the managed setting is the only way to turn it on.

## Expected

`toolSearchEnabled` is documented and behaves as a workspace-level setting. Enabling it should apply to every surface in the desktop app, including Chat.

## Actual

It applies to Cowork and Code. Chat behaves as though it is unset.

Measured on one machine, one account, one managed config, with an identical set of connectors enabled:

| Surface | Context consumed by tool schemas |
|---|---|
| Code | 0.4% |
| Chat | 5% |
| Cowork | honours the setting |

5% sounds survivable, but that was a light connector set. Users with a fuller set get exactly one query in Chat before the stream is interrupted with "too much context" and the session is unrecoverable.

Two related observations from the same investigation:

- Chat defaults new conversations to the 200k model rather than 1M, which compounds the problem, since the same inline schemas occupy five times the proportion of the window.
- In first-party (1P) mode on a claude.ai account, **Settings → Capabilities → Tool access mode / Connector search** are present and tool search is on by default. In 3P mode against a gateway base URL those settings are absent from the UI entirely, so the managed key is the only lever available, and on Chat it does nothing.

## Steps to reproduce

1. Put Claude Desktop in third-party (3P) mode against a custom inference base URL, with `toolSearchEnabled` set via MDM at the workspace level.
2. Enable several remote (HTTP) MCP connectors.
3. In the desktop app, open Code, run `/context`, note the share attributed to tool definitions.
4. In the same app, open Chat, run `/context`, and compare.
5. Send one substantive query in Chat.

Tool definitions occupy a much larger share in Chat than in Code, and step 5 terminates with a context error.

## Impact

This is the remaining blocker preventing us from rolling the desktop app out beyond engineering. Chat is the surface non-engineering users reach for first, and it is the one surface where the managed setting has no effect. The available workaround is to sign users back in against a first-party account, which defeats the purpose of routing through a gateway.

## Related

Existing reports covering adjacent parts of this behaviour, all currently closed or open without a fix:

- anthropics/claude-code#41472: `ENABLE_TOOL_SEARCH` not honoured in the Desktop app
- anthropics/claude-code#32378: tool search disabled when a custom base URL is set, via a capability check that inspects an internal model
- anthropics/claude-code#40314: tool search does not defer HTTP/streamable-HTTP MCP tools
- anthropics/claude-ai-mcp#401: "Load tools when needed" does not defer connector schemas
- anthropics/claude-ai-mcp#186: request for admin control over which MCPs are non-deferred

The distinct part here is the inconsistency between surfaces within one app under one managed setting, which suggests Chat reads its capability configuration from a different place than Cowork and Code.