V2: MCP discovery can starve chat reads in the client request queue #53049

Description

The app's request queue reserves slots for session reads when git/worktree requests are slow, but MCP and command catalogs are not classified as slow. Four catalog requests for different locations can occupy all four slots. A subsequent chat message request stays in the client queue even if the server could answer it immediately.

Command catalogs can wait for MCP startup/discovery. A slow or unavailable MCP server therefore delays unrelated chat reads until a catalog request completes or hits its header deadline.

OpenCode version

V2 2.0.22, based on d1f8f5b.

Steps to reproduce

1. Start four /api/command requests for different locations through createRequestQueue, holding their responses open.
2. Request /api/session/<id>/message through that queue.
3. Observe that all four catalogs are dispatched and the message request is not.

The same queue failure occurs for /api/mcp and /api/mcp/resource. A regression test demonstrates dispatch order; a loopback HTTP replay verifies that chat can complete before the held catalogs are released after the proposed fix.

Expected: discovery requests use the existing slow-request quota, preserving capacity for session reads. This is a reproduced starvation mechanism, not a claim that it explains every observed timeout.

Operating System

Debian GNU/Linux forky/sid, Linux x86-64.

Client and reproduction environment

OpenCode Desktop 2.0.22 on the workstation where intermittent chat loading was reported. The scheduler failure itself was reproduced with Bun 1.4.2 in the app queue test and a loopback HTTP fixture without plugins; it is not a CLI session-execution defect. A full Desktop trace correlating an original timeout to this mechanism has not been captured.