fix: forward ENABLE_OPENAI_CUSTOM_PROVIDER to container env

[bgrozev]

Summary

• ENABLE_OPENAI_CUSTOM_PROVIDER and OPENAI_CUSTOM_REQUIRE_WSS were missing from buildContainerEnvVars() in worker/index.ts, so they were never forwarded to the container process
• Added both vars to worker/env.d.ts (Worker type declarations) and buildContainerEnvVars() (container env forwarding)

Root cause

Worker environment variables are not automatically inherited by the container — they must be explicitly passed via buildContainerEnvVars(). Setting ENABLE_OPENAI_CUSTOM_PROVIDER=true in the CF dashboard had no effect because the container never received it.

Test plan

• Set ENABLE_OPENAI_CUSTOM_PROVIDER=true in CF Worker settings
• Connect with ?provider=openai_custom — should no longer get "Provider 'openai_custom' is not available"

🤖 Generated with Claude Code

[claude]

PR Review

Summary: Clean, minimal fix for a real bug — ENABLE_OPENAI_CUSTOM_PROVIDER and OPENAI_CUSTOM_REQUIRE_WSS were silently dropped on Cloudflare deployments because Worker env vars require explicit forwarding to containers. The root cause explanation is accurate and the fix is correct.

Correctness

The defaults in buildContainerEnvVars() match the server-side semantics in src/config.ts:

• ENABLE_OPENAI_CUSTOM_PROVIDER || 'false' — config reads === 'true', so 'false' is the right default ✓
• OPENAI_CUSTOM_REQUIRE_WSS || 'true' — config reads !== 'false', so 'true' is the right default ✓

The env.d.ts declarations are also correct (both string? optional), consistent with how other feature-flag env vars are typed.

Ordering

The two vars appear between TRANSLATION_MIXING_MODE and USE_DISPATCHER in env.d.ts, and after PROVIDERS_PRIORITY in buildContainerEnvVars(). Neither file has a strict alphabetical convention throughout, so this is fine.

Pre-existing unrelated issue (out of scope for this PR)

While reviewing the surrounding context I noticed that buildContainerEnvVars() forwards DEEPGRAM_DETECT_LANGUAGE (line 50), but src/config.ts reads process.env.DEEPGRAM_LANGUAGE — these names don't match. The forwarded var would be ignored by the container. This is pre-existing and unrelated to this PR, but worth a follow-up fix.

Verdict

LGTM. The fix is correct, the defaults are right, and no tests are needed for this type of env-forwarding wiring. The test plan in the PR description is appropriate.