Drive: Google's own Drive API through the connection, not its broker's actions

[pallaoro]

What changes

OpenVideo's Drive calls now go to Google's own Drive API through the org's connection: the broker signs each request, and the app never holds a token. That replaces the broker's action catalogue (*_FIND_FILE, *_GET_FILE_METADATA, *_DOWNLOAD_FILE, *_DELETE_FOLDER_OR_FILE), so the code is the same whoever holds the credential. It needs @clawnify/connections 0.7.0 (rawRequest, rawFile).

Call	Before	Now
Browse (the picker)	FIND_FILE	GET /files?q=… '<folder>' in parents …, across shared drives
Folder limit, names	GET_FILE_METADATA	GET /files/{id}?fields=name,parents; a 404 is "not visible", not an error
Delete a leftover copy	delete action	DELETE /files/{id}
Download, up to 250 MB	DOWNLOAD_FILE	GET /files/{id}?alt=media → a link to the bytes (rawFile)
Download, over 250 MB: footage	DOWNLOAD_FILE, up to the broker's disk (about 3.4 GB)	the shared link, as already for bigger files: whole, or a piece at a time
Download, over 250 MB: media library	DOWNLOAD_FILE	still DOWNLOAD_FILE, the one action left: nothing reads a library import in pieces

One API, two bases. Both connection types reach the same API, but their bases differ. Google Drive's base ends in /drive/v3, so the path is /files; Google Super's is the googleapis.com root, so the path is /drive/v3/files.

Size is checked first. A download asks for the file's size before anything else: the broker fetches a whole file into its own storage before refusing one over 250 MB.

A piece the shared link refuses comes through the connection

A file coming in by pieces (#61) now reads a piece from the connection when Drive refuses it on the shared link. Live today:

• Drive refused two 15 GB files' shared-link ranges past about 4.19 GB read (20 pieces): the 2040-byte quota page.
• The Drive API through the connection served the same range: 206, exact content-range.

Without this, those clips wait up to a day. The shared link stays first, because it is faster and costs no broker call. Once the connection has served a piece, the rest of that delivery reads from it.

Tests

• test/drive.test.ts, new, 11 tests through the real SDK:
  • each call's endpoint per connection type, query and headers;
  • 404 as "not visible";
  • small file as a link; big or size-unknown file never fetched whole;
  • the action fallback;
  • DELETE;
  • a piece's status, range and bytes; a refusal as its status.
• test/relay.test.ts:
  • a refused piece comes through the second reader, and the refusing link isn't asked again;
  • it waits on Drive only when every reader refuses;
  • a connection hiccup is left to the next step.
• End to end:
  • 12 now fakes the broker as it answers since the platform change: provider status inside, a file as a link. It asserts footage runs no Composio action, and that a file over 250 MB is never fetched whole through the broker.
  • 12b, new: a file whose shared link starts refusing part-way comes in through the connection, without waiting.
• Typecheck clean, 199 unit tests, end to end ALL OK.

pnpm-workspace.yaml gains a minimumReleaseAgeExclude for @clawnify/connections@0.7.0, which pnpm 11 added: the version was published today, and it is our own package.