Feature request: client-side chunking for OpenAI-compatible adapter to support duration-capped models (gpt-4o-transcribe / gpt-4o-mini-transcribe)

Start in internal/transcription/adapters/openai_adapter.go and trace the existing single-shot request to /v1/audio/transcriptions and its segment results. Implement the duration-capped path while preserving the unchanged path for uncapped models; done means chunk results form one continuous transcript with corrected original-file timestamps and overlap text handled.

Follow-up to #475 / #476.

OpenAI's newer transcription models (gpt-4o-transcribe, gpt-4o-mini-transcribe) reject audio longer than ~1400 seconds (~23 minutes) with a 400 error:

"audio duration 2158.5493333333334 seconds is longer than 1400 seconds which is the maximum for this model"

whisper-1 has no such duration cap (only the 25MB request-size limit, already addressed in #476), so it currently works for arbitrarily long recordings — but gpt-4o-mini-transcribe is half the price of whisper-1 ($0.003/min vs $0.006/min) and gpt-4o-transcribe has materially better accuracy for the same price. Neither is usable today for anything longer than ~23 minutes, which rules them out for typical meeting-length recordings.

Proposal: add chunking to the OpenAI-compatible adapter (internal/transcription/adapters/openai_adapter.go) for models that declare a duration cap:

• Split the input audio into sequential chunks under the model's duration limit (with a small overlap, e.g. 2-3s, to avoid cutting words at boundaries — or split on silence/VAD boundaries if that's already available in the pipeline, to avoid overlap-driven duplicate words entirely).
• Submit each chunk as a separate /v1/audio/transcriptions request.
• Reassemble the per-chunk segment results into one continuous transcript, correcting segment timestamps to be relative to the original file (not each chunk's own start), and de-duplicating any overlap-boundary text if the overlap approach is used.
• Only activate this path for models that actually need it (duration-capped models) — whisper-1 and other uncapped models should keep using the existing single-shot path unchanged.
• Model duration caps aren't likely exposed by an API — hardcode known caps (e.g. a small map of model ID → max duration seconds) with a sane fallback/documented assumption, and note in a comment that this may need updating if OpenAI changes the limit.

This is meaningfully more involved than #476 — real chunking + reassembly logic, not a preprocessing flag — flagging it as its own issue/PR rather than folding into that one.