gmail: MESSAGES_GET_COST_UNITS/GMAIL_QUOTA_UNITS_PER_SECOND are stale against current Gmail API docs

[newhoggy]

Context

While researching #1655 (gmail insert), the quota-unit costs and per-user rate ceiling src/gmail/messages_api.rs assumes were checked against Google's current Gmail API reference and found to have drifted:

pub const GMAIL_QUOTA_UNITS_PER_SECOND: u32 = 250;
pub const MESSAGES_GET_COST_UNITS: u32 = 5;

Google's documentation now states:

• messages.get costs 20 quota units, not 5.
• The per-user rate limit is 100 units/second, not 250.

These constants drive gmail sync's proactive TokenBucket pacing (src/cli/gmail/sync/engine.rs) and the MAX_CONCURRENCY/search_summaries concurrency bound (src/gmail/messages_api.rs). If Google's current numbers are accurate, sync's limiter is currently under-pacing relative to the real per-user ceiling — admitting up to 2.5x the actual allowed throughput — which would surface as elevated 429/rateLimitExceeded responses under sustained load rather than a silent failure (the client already retries those), but is worth tightening so the proactive limiter does its job instead of leaning on reactive retry.

Proposal

• Re-verify the current values against Google's Gmail API quota reference (they may have changed since this issue was filed too — recheck at implementation time).
• Update GMAIL_QUOTA_UNITS_PER_SECOND and MESSAGES_GET_COST_UNITS (and any sibling constants, e.g. MESSAGES_LIST_COST_UNITS, MESSAGES_INSERT_COST_UNITS added by feat(gmail): insert archived .eml messages into a mailbox (messages.insert) #1655) to match.
• Check whether MAX_CONCURRENCY (src/gmail/messages_api.rs) still makes sense relative to the corrected per-second ceiling.

Non-goals

Not a behavior change beyond constant values — no new pacing mechanism, no API surface change.

Noted but deliberately out of scope for #1655 rather than folded in, since it's pre-existing and orthogonal to gmail insert itself.