Gmail MCP search_threads returns stale/incomplete results for long-running threads; get_thread by ID is accurate

Summary: search_threads omitted multiple messages spanning ~2.5 weeks in an actively-threaded Gmail conversation, while get_thread called directly with the thread ID returned the complete, current message list instantly.

Repro:

1. A long Gmail thread ("Re: [subject]"), 14 total messages over ~2.5 weeks, alternating sent/received.
2. search_threads with a query matching the correspondent's address (also tried in:anywhere, includeTrash:true, newer_than:3d, and no date filter at all) consistently returned only 6 messages/threads, with this thread capped at its first 5 messages from early in the conversation — every message from roughly the second half of the timeline onward was missing, including messages received/sent the same day as the query.
3. get_thread({threadId: "<id>"}) on the same thread ID returned all 14 messages immediately, including the most recent ones from that morning.
4. Confirmed this wasn't general sync lag: a fresh self-test email sent during the session was indexed by search_threads within seconds — the staleness is specific to this (and presumably other) long/deep threads, not the mailbox as a whole.

Impact: Any workflow that relies on search_threads to confirm "did message X arrive" or "did I already reply" can silently return false negatives on active, long-running conversations — exactly the kind of thread most likely to matter (ongoing negotiations, recruiting, support tickets).

Suggested fix: Either refresh the search index more aggressively for threads with new activity, or have search_threads fall back to a live thread-message-count check rather than trusting a cached snapshot.