refactor(api): use canonical provider identifiers

[WebMad]

Summary

• replace raw provider string literals in buildApiHandler() with canonical providerIdentifiers
• use retiredProviderIdentifiers.roo for the dedicated Roo removal path
• preserve existing handler routing, retired-provider errors, and unsupported-provider fallback behavior
• expand focused handler-factory coverage for representative active, retired, and unsupported providers

Closes #955

Test plan

• cd src && npx vitest run api/__tests__/index.spec.ts api/providers/__tests__/friendli.spec.ts — 28 passed
• cd src && npx vitest run api — 2,035 passed, 2 skipped
• cd src && pnpm check-types
• repository pre-commit lint — 11 packages passed
• pre-push repository type checks — 11 packages passed

Summary by CodeRabbit

• Bug Fixes

  • Improved provider selection and routing for supported integrations.
  • Added clearer handling for retired or unsupported providers, including dedicated messaging where applicable.
  • Improved model-specific routing for Vertex integrations.

• Tests

  • Expanded coverage across provider types, fallback behavior, and unsupported-provider scenarios.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 715318d8-06a2-4bd9-9c11-0d21132afeb9

📥 Commits

Reviewing files that changed from the base of the PR and between d5a8c4a and a47f30a.

📒 Files selected for processing (2)

• src/api/__tests__/index.spec.ts
• src/api/index.ts

---

📝 Walkthrough

Walkthrough

buildApiHandler now uses canonical provider identifier constants for routing and retired-provider checks. Its tests mock handlers and cover the full provider mapping, Vertex model-specific selection, retired-provider errors, and unsupported-provider fallback.

Changes

API provider routing

Layer / File(s)	Summary
Canonicalize provider dispatch src/api/index.ts	buildApiHandler uses providerIdentifiers and retiredProviderIdentifiers for provider cases and the retired Roo check, preserving handler construction behavior.
Expand handler factory coverage src/api/__tests__/index.spec.ts	Tests mock provider handlers, validate the provider-to-handler mapping, cover Vertex model routing, verify retired-provider errors, and check unsupported-provider fallback.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• Zoo-Code-Org/Zoo-Code#952: Adds the canonical provider identifier exports consumed by this routing change.
• Zoo-Code-Org/Zoo-Code#991: Refactors related provider-selection logic to use canonical identifiers.
• Zoo-Code-Org/Zoo-Code#945: Adds explicit provider handling in the same buildApiHandler dispatch area.

Suggested labels: awaiting-review

Suggested reviewers: hannesrudolph

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: switching API handler selection to canonical provider identifiers.
Description check	✅ Passed	The description includes the linked issue, a concise change summary, and a test plan, so it covers the key required details.
Linked Issues check	✅ Passed	The changes match issue #955 by using canonical active and retired identifiers, preserving routing/errors, and expanding focused tests.
Out of Scope Changes check	✅ Passed	The diff stays focused on API handler selection and test coverage, with no unrelated feature or public API changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!