fix(objectstore): Set auth token in proxy endpoint, preprod task

[matt-codecov]

these appear to be the last objectstore auth integration issues to fix before we can turn on auth enforcement

proxy endpoint issue

there is a low volume of validation_failure / InvalidToken errors which only occur for requests to our batch endpoint. the only user of the batch endpoint appears to be sentry-cli, and those requests go through a Sentry proxy endpoint. the proxy endpoint forwards its request's headers mostly unmodified to Objectstore, including the Authorization header which contains a Sentry bearer token that Objectstore doesn't understand.

this PR creates a preprod objectstore session in the proxy endpoint and calls mint_token() to get a valid Objectstore token for the request

QUESTION: is it valid to assume the organization-based proxy endpoint will only deal with org-scoped resources? or do we need to make that a project-based endpoint

preprod task issue

we saw a surge in "no authorization token provided" issues coming from what i'm guessing are taskworker tasks? so i prepared the relevant task to receive a token kwarg. i assume actually setting it has to come in a separate PR, but i don't know how taskbroker tasks and whatall are deployed

Ref FS-321

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

[linear-code]

FS-321 Enable Authentication

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

New client created per task invocation instead of singleton

Medium Severity

create_client(token_override=storage_token) is called unconditionally, creating a new Client (with its own connection pool) on every task invocation. When storage_token is None — which is always the case currently since no caller passes it — the _get_session helper already falls back to the cached singleton via default_client() when client is None. The previous code used that singleton path. Now every compare_snapshots call needlessly allocates a new client, regressing from the caching that _OBJECTSTORE_CLIENT was designed to provide. The client creation with token override only needs to happen when storage_token is not None.