## What happened

A managed batch completes successfully, but repeated `GET /v1/batches/{id}` calls can turn its `output_file_id` or `error_file_id` into a nested managed ID. The stored provider mapping points at another base64 unified ID instead of the raw provider identifier.

Consequences:

- OpenAI/Azure: output/error download forwards a managed ID where the provider expects `file-*`, yielding 404/500. - Vertex: output download forwards a non-`gs://` value to the Vertex file transform, yielding `file_id must be a gs:// URI`.

## Reproduction

1. Run a managed batch via `/v1/files` and `/v1/batches`. 2. Let the batch complete, then retrieve it more than once (or allow the background cost poller to retrieve it before a caller does). 3. Inspect the managed output-file ID / `model_mappings`.

Expected `model_mappings`:

```json { "<model_id>": "file-..." } ```

or for Vertex:

```json { "<model_id>": "gs://bucket/path/predictions.jsonl" } ```

Actual: the mapping value is itself a base64 LiteLLM unified file ID.

## Root cause

`_PROXY_LiteLLMManagedFiles.async_post_call_success_hook` executes on every batch retrieve. It calls `get_unified_output_file_id` and stores `model_mappings…