[ENHANCEMENT] Make Gemini CLI handler routing explicit #1029

Problem (one or two sentences)

geminiCli is the only provider name without an explicit routing case in buildApiHandler, so it silently falls through to the default Anthropic handler. This makes the intended routing behavior unclear and easier to change accidentally.

Context (who is affected and when)

Contributors working on provider registration and API handler routing encounter this when reviewing or modifying src/api/index.ts. The gap was identified in review feedback on PR #1012: #1012 (comment)

Desired behavior (conceptual, not technical)

The Gemini CLI provider's current fallback behavior should be represented explicitly so readers can tell that using the Anthropic handler is intentional until a dedicated Gemini CLI handler exists.

Constraints / preferences (optional)

Keep the existing runtime behavior unchanged. The change should improve clarity without introducing a dedicated handler as part of this issue.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

N/A

Acceptance criteria (optional)

• Given the provider routing switch in buildApiHandler
• When a contributor reviews the supported provider names
• Then geminiCli has an explicit case
• And the case documents that it currently uses the Anthropic handler pending a dedicated implementation
• And runtime routing behavior remains unchanged

Proposed approach (optional)

Add an explicit case providerIdentifiers.geminiCli immediately before the existing default branch, with a short comment explaining the intentional fallback to the Anthropic handler.

Trade-offs / risks (optional)

The explicit case still shares behavior with the default branch, but this small duplication of routing intent is preferable to an undocumented implicit fallback.