feat(proxy): accept audio input on the OpenAI-compatible chat endpoint

Gemini accepts audio via `inlineData` with an `audio/*` mimeType — the
transcription handler already relies on that — but the OpenAI request
mapper never produced such a part:

* `audio_url` blocks hit a `tracing::debug!("Skipping audio_url ...")`
  stub, so audio was silently dropped and the model answered as if no
  attachment had been sent.
* `input_audio`, the format the OpenAI SDKs actually emit, had no enum
  variant at all, so the whole request failed deserialization with
  400 "data did not match any variant of untagged enum OpenAIContent".

Add a shared `audio_part_from_source()` helper that maps every common
audio reference to a Gemini part:

  data: URL      -> inlineData
  http(s) URL    -> fileData (fileUri)
  file:// / path -> read from disk, base64 -> inlineData
  bare base64    -> inlineData (mime from the declared format)

and wire it into both content-mapping sites (regular messages and tool
results), add the `input_audio` variant, pass audio parts through the
/v1/responses adapter, and account for `input_audio` in the context
token estimator (reusing the existing audio/* estimation).

Verified against a live Antigravity account: a 1s 16kHz WAV sent as
`input_audio` and as `audio_url` is now described by the model instead
of returning 400 / NO_AUDIO.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>