fix: wire up OpenAI-compatible provider in scenario/inject/script generation

[Darth-Ginger]

Problem

"AI Generated" scenario creation failed with:

AI scenario generation requires an active AI provider configured in the Admin → AI Config panel

even with a valid, connection-tested OpenAI-compatible provider set active.

ai-config.ts stores and connection-tests full OpenAI-compatible settings (baseUrl, apiKey, model), but every AI-generation entry point only ever branched on anthropic and ollama:

• generate-inject.ts: generateScenarioSetup / streamScenarioSetup / generateSingleInject / streamSingleInject — the "AI Generated" creator, called from routes/sessions.ts
• adaptive-inject.ts: generateAdaptiveInject — the "AI-Driven" mode, called from socket/index.ts — and generateAIDebrief (post-session debrief narrative)
• generate-script.ts: facilitator script generation (opening/round/closing scripts)

(generate-scenario.ts has the same pattern but its generateAIScenario function isn't called anywhere — left untouched.)

Related to #52, which fixed the same missing-openai-branch gap in the live-feedback resolver (services/ai/index.ts).

Fix

Adds an OpenAI-compatible branch (standard /v1/chat/completions endpoint) to each entry point above, modeled on the existing Claude/Ollama branches in the same files.

Also switches the setup/inject calls to use the configured (≥4000-floored) openai.maxTokens budget instead of Claude's tighter hardcoded 768/2048. Reasoning models exposed through an OpenAI-compatible endpoint (e.g. Gemini) spend hidden "thinking" tokens out of the same max_tokens budget, so a small budget gets exhausted before any visible JSON is emitted — which fails validation downstream (Missing scenario title) even though the request itself succeeded.

Testing

• npx tsc --noEmit — clean
• npx vitest run — 5 files / 16 tests passing
• Verified live against a self-hosted deployment pointed at Gemini's OpenAI-compatible endpoint: called generateScenarioSetup and generateSingleInject directly against the running container and got back valid, fully-formed setup/inject JSON (confirmed the fix end-to-end, not just a type-check).