Google Chat adapter: implement file upload support

[patrick-chinchill]

Missing capability — upstream also marks as TODO.

Current state

Python Google Chat `post_message` parses file attachments from messages but ignores them when posting (logs a warning and moves on):

• `src/chat_sdk/adapters/google_chat/adapter.py:1335-1340`

Upstream TS has the same stub — it's a multi-step API (upload to Drive → get a reference → attach to the message), and neither port has the full flow yet.

File downloads work via the `media.download` API — this issue is just uploads.

Why it matters

Consumers posting messages with attached files (screenshots, reports, generated artifacts) on Google Chat get silent drops instead of delivered attachments.

Fix

Implement Google Chat upload flow per Google's docs:

1. `POST /v1/media:upload` with multipart body to create a media reference
2. Use the returned attachment resource name in `messages.create` payload
3. Handle OAuth scopes (`chat.messages.create`) and service account auth

Acceptance

• `post_message` with `files=[FileUpload(...)]` uploads and attaches
• Works with both user OAuth and service account auth
• Regression test using recorded fixtures
• Entry in `docs/UPSTREAM_SYNC.md` non-parity table cleared

[patrick-chinchill]

Closing as no-op — Python already matches upstream behavior here.

Upstream TS (adapter-gchat/src/index.ts:1293-1301) does not implement file uploads; it logs a warning and leaves a TODO:

const files = extractFiles(message);
if (files.length > 0) {
  this.logger.warn(
    "File uploads are not yet supported for Google Chat. Files will be ignored.",
    { fileCount: files.length }
  );
  // TODO: Implement using Google Chat media.upload API
}

Python (src/chat_sdk/adapters/google_chat/adapter.py:1347-1354) does the same, at the same point in post_message, with the same warning text and same fileCount metadata:

files = extract_files(message)
if files:
    self._logger.warn(
        "File uploads are not yet supported for Google Chat. Files will be ignored.",
        {"fileCount": len(files)},
    )

Since upstream hasn't implemented media.upload yet, implementing it on the Python side would be a divergence, not a parity fix. When upstream lands the Drive/media flow, we'll port it under the regular upstream-sync cadence. Closing as not planned — will reopen (or track via the non-parity table) once upstream ships the feature.