bug: gmail +triage selects metadata scope and fails with q parameter (403)

[shuotao]

Body

## Summary
`gws gmail +triage` fails with `403 PERMISSION_DENIED` when OAuth token includes both:
- `https://www.googleapis.com/auth/gmail.metadata`
- `https://www.googleapis.com/auth/gmail.readonly`

The helper appears to use the metadata-capability path while still sending a `q` query, which Gmail rejects.

## Environment
- gws CLI: `0.7.0`
- Gemini extension: `google-workspace-cli v0.7.0`
- OS: macOS
- Auth: OAuth user token (valid), multiple Gmail scopes granted including `gmail.metadata`, `gmail.readonly`, `gmail.modify`

## Reproduction
1. Ensure OAuth token has both `gmail.metadata` and `gmail.readonly`.
2. Run:
   ```bash
   gws gmail +triage

3. Observe error:

   {
     "error": {
       "code": 403,
       "message": "Metadata scope does not support 'q' parameter",
       "status": "PERMISSION_DENIED"
     }
   }

Expected

gws gmail +triage should successfully return unread inbox summary (sender/subject/date), using a scope/method combination that supports query filtering.

Actual

+triage fails with 403 and does not return summary unless user/agent manually falls back to low-level API calls.

Notes

• Running low-level commands (e.g. gmail.users.messages.list + gmail.users.messages.get) can work in the same environment, which suggests token/scopes are not missing.
• This looks like helper-internal scope selection or query-path mismatch.

Suggested fix

• In +triage, prefer gmail.readonly (or compatible path) when using q.
• Or remove q when helper is forced to metadata-only behavior.
• Add a clearer error hint when metadata cannot support requested query options.

[SimonLeclere]

Fixed in the latest version