[BUG] Google Drive connector: read_file_content silently truncates Google Sheets at ~2,400–2,500 rendered cells per tab — no truncation marker

### What happened?

`read_file_content` on a Google Sheet returns a markdown rendering of the sheet. On tabs whose size exceeds ~2,400–2,500 cells, the rendering stops mid-tab with no error, no `truncated` field, no trailing marker. The response looks like a complete document; the only way to notice is to compare against the source.

Measured on synthetic sheets (1-character cells):

| Synthetic sheet | Cut row | Rows rendered (incl. header) | Cells rendered |
|---|---|---|---|
| 44 cols × 80 rows (8 KB file) | R054 | 55 | 2,420 |
| 10 cols × 260 rows | R248 | 249 | 2,490 |

The 8 KB file size rules out a byte limit. Since 2,420 ≠ 2,490 the budget is not an exact cell count — it looks like a character/token budget on the markdown rendering, so longer cell contents cut proportionally earlier. The behavior is deterministic: same file → same cut row across two sessions and two different models on the same day (2026-08-06/07, claude.ai Cowork cloud session).

Real-world impact: on a production HR spreadsheet, a 44-column tab with 1,071 rows rendered only 54 data rows. An automated payroll pre-check declared a person "missing from the registry" (they sat on row 58) and ran completeness checks over less than half the company while believing the data was complete. A noisy error costs ten minutes; a partial read that looks complete silently invalidates every downstream check built on it.

Related detail: `download_file_content` with `exportMimeType: "text/csv"` on the same spreadsheet returns a complete, correct export — but only of the first tab, with no way to select another tab. So the export path is healthy; the truncation is specific to the multi-tab markdown rendering of `read_file_content`.

### What did you expect to happen?

First and foremost: I expect `read_file_content` to return the complete content of the sheet — an 8 KB file with 80 rows is nowhere near any reasonable context limit, and the tool gives no indication that reading it in full is not supported.

If a rendering limit must exist, then failing safely would require any of the following (in descending order of preference):

1. An explicit `truncated: true` field (ideally with `renderedRows`/`totalRows` per tab) in the response.
2. A visible trailing marker in the rendered text, e.g. `… [output truncated: 54 of 1071 rows shown]`.
3. Pagination / range parameters (`tab`, `startRow`, `maxRows`) so callers can read large tabs in slices.
4. At minimum: the limit documented with numbers (the current docs only say files must "fit within the context window", with no mention of silent truncation).

What must never happen is the current behavior: a response that looks complete and gives the caller no way to detect that data is missing.

### Steps to reproduce

1. Create a CSV with 44 columns × 80 data rows: header `COL01,C02,…,C44`, then rows `R001,x,x,…,x` through `R080,x,x,…,x`. Upload via `create_file` with `contentMimeType: text/csv` and conversion to Google Sheet (total size: 8 KB).
2. Call `read_file_content` on the resulting Sheet.
3. Actual: rendering contains header + rows R001…R054. Rows R055–R080 are absent. No error, no marker.
4. Repeat with 10 columns × 260 data rows → rendering stops at R248.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

Google Drive (Anthropic first-party connector on Claude.ai / Cowork)

### Error messages or logs

```shell
None — that is the core of the bug. The tool call succeeds and returns a well-formed markdown table that simply stops mid-data, with no truncation indicator of any kind.
```

### Additional context

This appears to be part of a wider pattern of connectors capping output without markers: #239 and #296 (Gmail threads), #747 (Microsoft 365 folder listings), #587 (tool list capped at 256). The silent variant is the worst possible failure mode for agentic use: neither the model nor the user can know the data is partial.

The sibling problem on the binary transport path is documented in anthropics/claude-code#50358 (create_file silently truncates binary uploads; auto-closed as stale without a fix) and anthropics/claude-code#54137. We have posted fresh August 2026 measurements there.

Observed on claude.ai Cowork (cloud session), account on a Team/Enterprise-style org, Google Drive connector tools: search_files, get_file_metadata, read_file_content, download_file_content, create_file.