OpenAI-compatible engine: 3000 s default batch (and hard-coded retranscribe cap) is incompatible with the fixed 30 s request timeout

Summary

With audioTranscriptionEngine = openai-compatible and transcriptionMode = batch, screenpipe 2.7.28 sends batches of up to 3000 s (~50 min) of audio in a single POST /v1/audio/transcriptions, while the HTTP client for that engine has a fixed 30 s timeout. Any server that is slower than ~100× realtime cannot succeed, so the batch fails with a timeout, the client retries, and the server keeps burning GPU on an orphaned request.

Where

• crates/screenpipe-audio/src/audio_manager/reconciliation.rs — default_max_batch_duration_secs: OpenAICompatible => 3000 (comment: "user-configurable (unknown engine limits)").
• crates/screenpipe-audio/src/transcription/stt.rs — OPENAI_COMPATIBLE_TIMEOUT_SECS = 30, applied to the reqwest client (also used by openai_compatible/batch.rs, which retries on timeout with backoff).
• crates/screenpipe-engine/src/routes/retranscribe.rs — meeting_retranscribe_max_batch_duration_secs: OpenAICompatible => 3000 hard-coded; it does not honor the user's batchMaxDurationSecs setting, so even a user who lowered the batch size gets a 50-minute request from the meeting "retranscribe" action.

Observed

• Self-hosted faster-whisper-large-v3 (speaches) behind a gateway, ~0.05–0.1× realtime on a shared RTX 3090.
• Reconciliation batches of >17 min and a retranscribe request of 50:03 → 504 Gateway Timeout after 25 s (gateway) / would be 30 s (client), retried 3×, each retry leaving another multi-minute job running server-side (speaches-ai/speaches#129: no cancel on disconnect).
• Notification "OpenAI Compatible transcription is failing".
• batchMaxDurationSecs was null (default) in the store.

Expected

1. meeting_retranscribe_max_batch_duration_secs should honor batchMaxDurationSecs (like reconciliation does), falling back to the engine default.
2. The OpenAI-compatible default batch size and the request timeout should be consistent: either scale the timeout with the batch duration (e.g. max(30, batch_secs)), or use a much smaller default (e.g. 120–300 s) for an engine whose speed is unknown.

Workaround

Set batch_max_duration_secs (settings › advanced) to a value the server can handle within 30 s (120 s in our case). This fixes reconciliation but not the retranscribe action because of the hard-coded cap.

Happy to open a PR for (1) — it is a small change in retranscribe.rs.