[BUG] Cowork: MCP elicitation/create silently auto-cancels (reproduced with a different MCP server than #56243/#48164)

### Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported (as an open issue) — it was previously filed as #56243, auto-closed by a bot as a duplicate of #48164, then auto-locked after 7 days of inactivity so it can no longer receive comments. I believe #48164 is a distinct, narrower bug (server-initiated OAuth elicitation with `mode: "url"`), not the same failure as this one (plain form/confirm elicitation).
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code available in Claude Desktop

### What's Wrong?

In Claude Desktop's Code tab (Cowork), when a connected MCP server sends an `elicitation/create` request (a plain confirm/decline form, no URL mode, no OAuth), the client returns almost instantly with the elicitation reported as declined. No UI is ever rendered, and the user sees nothing to respond to — at most a macOS notification that appears and disappears before it can be read.

From the MCP server's point of view, this response is indistinguishable from a real, deliberate user decline. That matters because it breaks the server's own graceful-degradation path: our server has a documented fallback specifically for clients that don't support elicitation (it stages the write and returns a `pending_id` the user can confirm later via a separate tool call, with the preview shown as plain chat text). That fallback never triggers here, because Cowork's client *does* apparently acknowledge the elicitation request — it just answers it with an immediate synthetic decline rather than either rendering the prompt or signaling non-support during capability negotiation.

### What Should Happen?

One of two things, matching what already happens correctly elsewhere:
1. Cowork renders the elicitation prompt inline (as the terminal Claude Code CLI's TUI now does per #17043 in this repo), and blocks the tool call until the user responds, or
2. If rendering isn't implemented for this surface, Cowork should not declare/acknowledge the `elicitation` client capability at all, so MCP servers can detect non-support up front and take their own fallback path (as ours does) instead of receiving a false "user declined."

### Steps to Reproduce

1. Connect Claude Desktop to a remote MCP server whose write tool triggers `elicitation/create` (a plain confirm/decline schema) before completing a write. (Any server implementing this — ours is an accounting product's MCP server, unrelated to whatever server was used in #56243.)
2. In Claude Desktop, open a session using the Code tab (Cowork) with that MCP server connected, in the same project scope.
3. Trigger the write tool.
4. Observe: the tool call returns within roughly 50ms reporting the write was cancelled/declined. No confirmation UI is shown. The MCP server's own fallback (`pending_id` staging) is never offered because the client's response looks like a genuine decline, not an "elicitation unsupported" signal.
5. For comparison, connect the *same* MCP server to the terminal `claude` CLI and trigger the same tool: elicitation still isn't rendered as a native dialog there either, but the server's staged-write fallback works correctly, shows a text preview, and completes the write once the user replies "yes" and the client calls the server's confirm-write tool.

So the terminal CLI ends up in a working state via graceful degradation, while Cowork ends up in a silently broken state that's indistinguishable from a real user rejection.

### Error Messages/Logs

No error is surfaced to the user. The MCP server's write tool response was:
```json
{"ok": false, "cancelled": true, "message": "Avbrutet — inget utlägg skapades."}
```
(Swedish for "Cancelled — nothing was created.")

### Claude Model
Sonnet (default) — Claude Sonnet 5 (`claude-sonnet-5`)

### Is this a regression?
I don't know — this is the first time I've used an MCP server with an elicitation-based write tool from Cowork.

### Claude Code / Claude Desktop Version
Claude Desktop 1.52386.6 (Code tab / Cowork surface)

### Platform
Anthropic API

### Operating System
macOS 26.5.1 (build 25F80)

### Terminal/Shell
N/A — this is Claude Desktop's Code tab, not a terminal surface

### Additional Information

Related: #56243 (my independent reproduction of the same symptom, now locked and unable to receive comments), #48164 (the issue #56243 was auto-closed as a duplicate of — appears to cover a different, more specific case: `elicitation/create` with `mode: "url"` for server-initiated OAuth flows, not general form-based elicitation), #2799 and #17043 (elicitation support landing correctly in the terminal Claude Code CLI).

Happy to provide a minimal reproduction MCP server if that would help — the one I hit this with is a third-party production service I can't share credentials for, but the failure is generic to any server using `elicitation/create`.