## What happened

A managed OpenAI batch can complete while `GET /v1/batches/{id}` returns a raw provider `output_file_id` (`file-*`) instead of an owned base64 unified managed-file ID. Calling `GET /v1/files/{file-*}/content` then falls through to the generic OpenAI file path, which has no deployment API key and fails with:

```text The api_key client option must be set either by passing api_key to the client or by setting the OPENAI_API_KEY environment variable ```

Raw output IDs also bypass the managed-file ownership pre-call hook, creating a cross-user authorization risk if a caller obtains another user's raw file ID.

## Reproduction

1. Configure a managed OpenAI batch deployment with per-deployment `api_key` / `api_base` rather than global `OPENAI_API_KEY`. 2. Upload managed input via `/v1/files`, create `/v1/batches`, and wait for completion. 3. Retrieve the managed batch during the terminal DB-read path when no managed-file row exists for the raw provider output ID. 4. Call `/v1/files/{output_file_id}/content`.

Actual: a raw `file-*` is returned and content retrieval 500s due to missing credentials.

## Root cause

The terminal-state path calls `resolve_output_file_ids_t…