Integration: Support for GCP buckets

[vprashrex]

Is your feature request related to a problem?
We lack integration with Google GCP buckets, which hinders users from resolving private attachment URLs using their own credentials. This limits the potential for assessments involving these private URLs.

Describe the solution you'd like

• Integrate Google GCP bucket support to allow users to provide service account JSON keys.

• Enable private URL resolution using provided credentials.

• Implement pathways for:

  • Path A: Directly push URLs for Vertex providers.
  • Path B: Sign URLs to public with a TTL of 24 hours for other providers.

• Doc: https://docs.google.com/document/d/1gL94Mm07LNQX_Dj1LRdkmfRWxhj8nGKvOsABDdd_elc/edit?tab=t.0#heading=h.p65szbqr48gi

[kartpop]

A few additional implementation details/constraints worth capturing beyond the original description:

Abstraction requirements

• The assessment pipeline should not contain the if/else routing logic. Suggest a convert_to_public_url-style utility taking source URLs + destination provider and returning usable URLs, acting as a no-op when the input is already public.
• Support GCS, AWS S3, and plain HTTPS as source types initially; extensible later.
• Introduce a BucketProvider class hierarchy mirroring the existing LLMProvider pattern (GCS first, S3 later).
• Return a map keyed by assessment row ID → URL rather than an index-matched list, since index matching across input/output lists is error-prone. A batch may assume a single source bucket, but the map structure is still preferred.

Path A constraint: the bucket referenced in the service-account credential must be the same bucket the attachments live in.

TTL: should be configurable (1h/24h both discussed) rather than fixed at 24h.

Testing plan: validate both GCS pathways with small standalone scripts — insert a service-account credential row in the credentials table (mimicking partner setup), drop a test JPG in the bucket, and verify read access via (a) direct URI to Vertex and (b) signed URL. S3 doesn't need retesting since the signed-URL flow is already proven.

fyi: @vprashrex

Related: PR #1138 (open), PR #1131 (open)