[BUG] Gmail search_threads returns stale, capped 5-message snapshot for long threads

### What happened?

## Bug: Gmail `search_threads` tool returns a stale, capped message list for long email threads

**Summary:** For a single Gmail thread containing 20+ messages spanning roughly 16 months, the `search_threads` tool consistently returned only 5 messages, frozen at a point roughly 2 months out of date — regardless of how the thread was queried.

### What did you expect to happen?

All threads should have returned

### Steps to reproduce

**Reproduction steps:**
1. Query `search_threads` for a long-running email thread (20+ messages, same subject/participants) using a variety of distinct search terms — including the thread subject, a participant's email address, and several unique phrases/keywords that only appear in the most recent messages of the thread.
2. Every query returns the identical thread ID with an identical 5-message array, regardless of which search term was used.
3. Confirmed via a targeted test: querying with a sender address that does not appear as a sender in any of the 5 returned messages (but does appear in later messages) still returned the same stale 5-message snapshot.
4. The most recent message actually in the thread (confirmed by the user pasting the raw email content) was sent same-day. The tool never surfaced it, nor 14+ other messages between the stale cutoff and present day.

### Area

MCP Connector (adding/managing servers)

### MCP Server (if applicable)

_No response_

### Error messages or logs

```shell

```

### Additional context

Full context produced by Claude:
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet (closest related: #349, #47024 — both distinct symptoms, see note below)
- [x] This is a single bug report
- [x] I am using the latest version of the Claude app

Environment
- Platform: Android (Claude app)
- Date/time observed: July 29, 2026, ~5:00 PM ET
- Connector: Gmail (first-party MCP)

## Bug: Gmail `search_threads` tool returns a stale, capped message list for long email threads

**Summary:** For a single Gmail thread containing 20+ messages spanning roughly 16 months, the `search_threads` tool consistently returned only 5 messages, frozen at a point roughly 2 months out of date — regardless of how the thread was queried.

**Reproduction steps:**
1. Query `search_threads` for a long-running email thread (20+ messages, same subject/participants) using a variety of distinct search terms — including the thread subject, a participant's email address, and several unique phrases/keywords that only appear in the most recent messages of the thread.
2. Every query returns the identical thread ID with an identical 5-message array, regardless of which search term was used.
3. Confirmed via a targeted test: querying with a sender address that does not appear as a sender in any of the 5 returned messages (but does appear in later messages) still returned the same stale 5-message snapshot.
4. The most recent message actually in the thread (confirmed by the user pasting the raw email content) was sent same-day. The tool never surfaced it, nor 14+ other messages between the stale cutoff and present day.

**Why this looks like a caching/pagination bug rather than a relevance-ranking issue:** If this were a search-relevance problem, different queries should surface different (if still imperfect) results. Instead, every query — including ones with zero textual overlap with the 5 returned messages — converged on the exact same fixed snapshot. This suggests `search_threads` may cap returned messages-per-thread at ~5 and serve a cached/stale thread state rather than live data.

**Secondary observation (same session, likely related):** A date-bounded query for Sent mail from the account also appeared to stall at a fixed date roughly 3 days prior to the actual current date, while Inbox queries in the same session correctly returned same-day messages. This may be the same underlying issue manifesting in a different query path.

**Impact:** Any workflow relying on `search_threads` to retrieve the current state of an active, long-running email conversation may silently work from outdated information with no error or warning surfaced to the user or the model.

**Relation to existing issues:** This differs from #47024 (hard "Internal error" on every call) and #349 (sender-specific empty results) — here, the tool succeeds and returns plausible-looking data, but it's a fixed, capped, stale snapshot regardless of query. Possibly the same root cause (thread-state caching) manifesting differently.