Two defects exposed by #11226 (the 401 "User not found." itself is upstream
OpenRouter's response to a bad key — not an OmniRoute bug):
1. OpenRouter key validation was vacuous. Both the dashboard Check (via
validateProviderApiKey -> validateOpenAILikeProvider) and 'omniroute
providers test' (bin/cli/provider-test.mjs) probed /api/v1/models, which is
PUBLIC and answers 200 to any key — so invalid keys were saved/marked valid
and only failed on real chat traffic. OpenRouter's authenticated key-info
endpoint (GET /api/v1/auth/key, 200 = valid / 401 = invalid) is now the
probe: registered as testKeyModelsUrl on the openrouter registry entry
(same mechanism as perplexity) and as keyCheckPath in the CLI test configs.
No other provider's probe changes; error results keep using canned strings,
never the raw upstream body (Hard Rule #12).
2. 'omniroute auth export' crashed with "cmd.optsWithGlobals is not a
function". .command("auth export") does not register a two-word command:
commander parses the bare word 'export' as a required positional argument,
so the action received (exportArgValue, options, command) while expecting
(options, command). Registered 'export' as a proper nested subcommand of
'auth' — the documented CLI surface 'omniroute auth export [--force]
[--id] [--format] [--out]' is unchanged, and unknown positionals
(e.g. 'omniroute auth bogus') are now rejected instead of silently running
the export.
TDD: tests/unit/openrouter-key-validation-auth-endpoint.test.ts (stub mimics
the real OpenRouter: /models public-200, /auth/key 401 'User not found.') and
tests/unit/cli-auth-export-wiring.test.ts (real commander wiring via
createProgram) were RED before the fix and are GREEN after.
Co-authored-by: Xiangzhe <bakryun0718@proton.me>
5cf16028fe