fix(cli): give setup-claude a fallback profile generator like setup-codex

[derhornspieler]

Summary

• setup-codex.mjs has fallbackCodexProfile() so any live-catalog model not matched by the hardcoded categoriseModel() pattern list (glm/kimi/mimo/deepseek/gemma4/…) still gets a generated profile. setup-claude.mjs never got the equivalent — so any catalog that doesn't contain those specific old model names (e.g. a fresh install using a custom OpenAI-compatible provider) silently produces zero Claude Code profiles, just "0 written, N skipped" with no error.
• Adds fallbackClaudeProfile(), reusing the already-exported isCodexCompatibleTextModel() filter and a newly-exported profileNameFromModelId() helper from setup-codex.mjs, wired the same way setup-codex.mjs wires its own fallback: categoriseModel(id) ?? fallbackClaudeProfile(id, m).
• Repro'd against a real OmniRoute instance configured with a mix of claude/*, codex/*, and custom self-hosted OpenAI-compatible provider models (no glm/kimi/mimo matches) — omniroute setup-claude went from 0 profiles written / 59 skipped to profiles generated for every compatible text model.

Related Issues

• Closes #
• Related to #

Validation

• npm run lint — 0 errors (4270 pre-existing any warnings, unrelated to this change)
• npm run test:unit (full monorepo suite) — ran to completion. 15 pre-existing failures across 5 files (combo-builder-opencode-prefix, copilot-runOmniRouteCli, guardrails/visionBridgeHelpers.callVisionModel, kiro-multi-account-isolation, provider-translate-path-golden), verified identical on the unmodified base commit (32e4c906e, same test names, same counts) — confirmed pre-existing/environment-sensitive (local machine state), not caused by this change. Zero failures in any file this PR touches.
• npm run test:coverage — not run locally; this is a 2-function, ~20-line addition to existing CLI helper modules, low coverage-impact surface
• SonarQube PR analysis — will run in CI

Tests Added Or Updated

• tests/unit/cli/setup-claude.test.ts:
  • fallbackClaudeProfile creates a profile for a live-catalog model unmatched by categoriseModel
  • fallbackClaudeProfile skips media and non-text models
  • syncClaudeProfilesFromModels falls back to a generic profile for unmatched catalog models
• All 15/15 tests in this file pass (12 pre-existing + 3 new); tests/unit/cli/setup-codex.test.ts (3/3) and the full tests/unit/cli/*.test.ts suite (92/92) also verified green.

Coverage Notes

• Touches bin/cli/commands/setup-claude.mjs (new fallbackClaudeProfile export + one-line change to the categoriseModel(id) call site) and bin/cli/commands/setup-codex.mjs (exports the previously-private profileNameFromModelId helper — no behavioral change, existing setup-codex.test.ts suite still passes 3/3 unmodified).
• New code is covered by the 3 new tests listed above, following the exact same test pattern already used for fallbackCodexProfile in setup-codex.test.ts.

Reviewer Notes

• No production src//open-sse/ code touched — this is CLI-helper-only (bin/cli/commands/).
• profileNameFromModelId export is additive (was already a pure function, just unexported); no call sites elsewhere reference it, verified via repo-wide grep before exporting.
• Branch was cut from release/v3.8.44 per repo convention (not main).
• Full-suite failures were diffed against base commit 32e4c906e (same worktree, files reverted then restored) rather than assumed pre-existing — see Validation section.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[diegosouzapw]

Merged — thank you, @derhornspieler! 🙏 Good catch on the asymmetry: setup-codex.mjs has fallbackCodexProfile() so any live-catalog model unmatched by the hardcoded categoriseModel() pattern list still gets a generated profile, but setup-claude.mjs never got the equivalent — so a fresh install using a custom OpenAI-compatible provider silently produced zero Claude Code profiles. Mirroring it with fallbackClaudeProfile() (reusing categoriseModel/profileNameFromModelId from setup-codex, exports widened additively) is exactly right. Your 2 new tests genuinely guard it (the file fails to load without the fix), and the 13 existing tests still pass. Ships in the next release.