Improve Gmail threads.list and threads.get conformance

[Bbbstin]

Summary

• make threads.list deterministic by ordering threads by their latest visible member message, falling back to the latest member for fully hidden threads, with a stable thread ID tie-breaker before offset pagination; persisted Thread rows with no member messages are no longer listed
• align threads.list label filtering with Gmail by requiring one member message to satisfy all requested labelIds
• align threads.get with the read contract by ordering messages deterministically, limiting format to full, metadata, and minimal, and treating the same empty-thread orphan state as not found
• add focused behavior coverage for thread-wide search, same-message multi-label filtering, includeSpamTrash, result estimates, pagination, same-subject thread identity, formats, and orphan handling
• strengthen conformance coverage with sanitized provider fixtures for list, full, metadata, minimal, mixed Trash/Spam ordering, and multi-label filtering

Validation

• cd packages/environments/mock-gmail && uv run --extra dev pytest tests/test_conformance.py -q (43 passed)
• cd packages/environments/mock-gmail && uv run --extra dev pytest tests -q (260 passed)
• git diff --check

Notes

• sanitized real Gmail captures back the list, full, metadata, and minimal response shapes, mixed Trash/Spam ordering, and same-message multi-label filtering; official Gmail documentation backs thread-wide search and the supported get formats
• no Gmail credentials, OAuth tokens, raw account identifiers, or unsanitized captures are tracked
• this branch is based directly on main and is independent of Fix Gmail multi-label filtering #26 (both touch tests/test_api.py, but in unrelated tests: Fix Gmail multi-label filtering #26 adds message-list filtering coverage, while this PR only makes the thread-deletion setup deterministic)
• scripts/smoke_dev.sh and Docker/base-image checks are not applicable because this PR does not change launcher, control, devhub, Docker, or base-image behavior
• no Web UI, write-side message or draft behavior, seed data, database schema, attachment/history/snapshot behavior, or security-sensitive ownership logic is changed