fix: allow non-OpenAI providers to skip OPENAI_API_KEY check

[professional-slacker]

Summary

This PR fixes a validation bug where OpenClaude incorrectly mandates an OPENAI_API_KEY even when using providers that either don't require authentication (e.g., gitlawb-opengateway) or use their own specific environment variables (e.g., XXXXX_API_KEY).

The Problem

The current validation logic in src/utils/providerValidation.ts has a final fallback that forces OPENAI_API_KEY presence if CLAUDE_CODE_USE_OPENAI is truthy (which is often the case when an OpenAI profile is active in ~/.openclaude.json).

This causes:

1. Bad UX: In interactive mode, users see confusing warnings like "Provider configuration is incomplete" even when the provider is correctly configured via other means.
2. Fatal Failure: In non-interactive mode (--print), this validation error is fatal, preventing OpenClaude from running at all in automated environments.

This is especially problematic for new users trying to use "FREE" providers like Gitlawb Opengateway, where they are met with a "Key required" error despite the UI promising a free, no-auth experience.

Note: This PR focuses on fixing the validation gate issues. We are aware of the deeper configuration redundancy issues (dual management between profiles and env vars) but have opted to skip addressing them in this PR to keep the scope focused on restoring immediate functionality.

Changes

• Validation Logic: Updated getProviderValidationError to skip the OPENAI_API_KEY check if:
  • The provider descriptor explicitly sets requiresAuth: false.
  • Any of the provider's specific credentialEnvVars are present in the environment.
• Provider Metadata: Added missing validation metadata to src/integrations/gateways/gitlawb-opengateway.ts.

Evidence (Reproduction with --print)

# Before Fix (v0.12.0) - Fails despite using a free provider
$ OPENAI_API_KEY="" openclaude --provider gitlawb-opengateway --print "hi"
OPENAI_API_KEY is required when CLAUDE_CODE_USE_OPENAI=1... (Process Exits)

# After Fix (v0.12.0-mod) - Works as expected
$ OPENAI_API_KEY="" openclaude --provider gitlawb-opengateway --print "hi"
Hi! How can I help you today?

[jatmn]

Findings

• [P2] Add a regression test for the Opengateway no-auth path
  src/utils/providerValidation.test.ts
  This PR fixes a fatal startup validation path for gitlawb-opengateway, but the provider validation tests still only cover adjacent OpenAI-compatible providers such as MiniMax, OpenRouter, DeepSeek, Moonshot, and Xiaomi MiMo. Because this bug only appears when CLAUDE_CODE_USE_OPENAI=1, OPENAI_BASE_URL points at opengateway.gitlawb.com, and OPENAI_API_KEY is absent, it is easy to regress by changing descriptor routing or the fallback OpenAI key check later. Please add a focused test that asserts getProviderValidationError returns null for the Opengateway base URL without OPENAI_API_KEY.

[professional-slacker]

Thanks for the review! I've added the requested regression tests:

1. Base path test: https://opengateway.gitlawb.com/v1 without OPENAI_API_KEY → returns null
2. Model-specific path test: https://opengateway.gitlawb.com/v1/xiaomi-mimo without OPENAI_API_KEY → returns null

Both tests verify that getProviderValidationError correctly skips the mandatory OPENAI_API_KEY check when the provider is requiresAuth: false (opengateway).

All 22 tests pass:

22 pass
0 fail
31 expect() calls

[gnanam1990]

Thanks for tracking this down and adding the regression tests jatmn asked for — the no-auth UX problem with Gitlawb Opengateway is real and worth fixing.

A couple of things came up during local verification:

1. Typecheck regression. bun x tsc --noEmit now fails with:

src/utils/providerValidation.ts(481,66): error TS2339: Property 'kind' does not exist on type 'never'.

This is new on this branch (clean on main). The build still succeeds because the build step doesn't run tsc, but we gate on a clean typecheck.

2. The fix may already be complete via the descriptor. Tracing the validation flow for the opengateway scenario (CLAUDE_CODE_USE_OPENAI=1, base URL opengateway.gitlawb.com, no OPENAI_API_KEY): the runtime target resolves to the gateway via matchBaseUrlHosts, getDescriptorValidationError returns null, and getProviderValidationError returns null before ever reaching the new branch at lines 472–489. I confirmed empirically — reverting just the providerValidation.ts hunk and keeping only the gitlawb-opengateway.ts descriptor change, all 22 providerValidation.test.ts tests still pass, including both new ones. So the descriptor metadata is doing all the work and the providerValidation.ts changes are unreachable (which is why TS narrows to never there).

Dropping the providerValidation.ts hunk entirely would resolve the typecheck error, remove the unreachable branch, and still fix the reported bug with tests green. One small thing while you're in the descriptor: matchBaseUrlHosts lists opengateway.fly.dev alongside opengateway.gitlawb.com — is that an intentional supported host? It's not referenced anywhere else.

Could you rework down to the descriptor change (plus the tests) and confirm bun x tsc --noEmit is clean? Happy to re-review quickly after that.