[BUG] "Tool result could not be submitted" banner appears on successful tool calls with streamable-http transport`

### What happened?

## Summary

When using a custom MCP connector that exposes the `streamable-http`
transport over a Cloudflare tunnel, Claude.ai's web and desktop UI
intermittently displays a yellow banner reading:

> *"Tool result could not be submitted. The request may have expired or
> the connection was interrupted. Refresh the page to continue."*

The banner appears **even when the tool call succeeded** and the returned
data is correctly rendered in the chat. Reloading the page loses
context unnecessarily, so the banner is a false alarm in these cases.

## Environment

- **Claude.ai**: both web (Chrome on Windows) and Desktop (Windows)
- **Claude model**: Sonnet
- **MCP server**: Python 3.x + FastMCP (streamable-http transport),
running on port 8081 locally, exposed via a named Cloudflare tunnel
to a public HTTPS hostname.
- **Affected tools**: multiple; banner appears regardless of which
tool is called, though more frequently on tools that return larger
payloads (~50 KB+).

### What did you expect to happen?

No error popup bar

### Steps to reproduce

## Steps to reproduce

1. Stand up a FastMCP server with the streamable-http transport on
port 8081.
2. Expose via a Cloudflare named tunnel to an HTTPS hostname.
3. Connect the tunnel URL as a custom connector in Claude.ai
(web or desktop).
4. Start a new chat and invoke any tool that returns structured data
(e.g. a listing of 50+ records).
5. The tool returns data correctly and Claude renders the answer.
6. Shortly after, the banner appears top-right.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

_No response_

### Error messages or logs

```shell
## Evidence

### Cloudflared tunnel log (shows graceful cancels with HTTP/2 error code 0)

2026-04-22T19:35:31Z ERR error="stream 5 canceled by remote with error code 0"
connIndex=1 event=1 ingressRule=0 originService=http://localhost:8081
2026-04-22T19:35:31Z ERR Request failed error="stream 5 canceled by remote
with error code 0" connIndex=1 dest=https:///mcp?api_key=...

`error code 0` = `NO_ERROR`, i.e. the remote (Claude.ai) closed the
stream gracefully. But Claude.ai's UI surfaces the close as if it was
a submission failure.

### Server side: tool call returns cleanly

Python logs from the same chat window showing the tool call ran
successfully and returned the expected rows. Claude's chat bubble
then correctly quotes the data. The banner still fires.

## Mitigations we already applied server-side

- Paginated every listing tool (default `limit` 50-100, explicit
`offset`).
- Response sizes brought down from 100-300 KB to 50-75 KB typical,
worst case ~110 KB for deep KPI snapshots (users opt in).
- Trimmed verbose fields from default responses.

The banner frequency decreased but did not go away. It also fires on
small responses (<10 KB), which suggests the banner is not purely
size-driven but related to how Claude.ai's SSE consumer interprets a
post-response stream close.

## Suggested investigation areas

1. Does Claude.ai's SSE consumer treat an HTTP/2 graceful close
(`error code 0`) after a `message` event as an abnormal termination?
2. Is there a race between Claude.ai receiving the tool result and
consuming the final SSE frame before the server's
`StreamableHTTPSessionManager` closes the transport?
3. Could the banner be dismissed automatically when the preceding
`tools/call` result was successfully received and rendered?

## Impact

- **Subscriber trust**: users think their query failed when it didn't.
- **Support burden**: we get questions about it multiple times per
session from testers.
- **Prompts the user to refresh**, which loses chat state.

## Request

Please consider either:
- Fixing the underlying false-alarm condition so the banner only shows
on actual tool-result submission failures; or
- Silencing the banner when the corresponding tool call was received
and displayed.
```

### Additional context

_No response_