Native Gemini routing for arbitrarily-named external endpoints: carry a profile key through chat params

[wch]

Follow-up to #61 (Databricks native APIs), which defers this.

Problem

Databricks native Gemini routing (google-generative protocol stamp) is restricted to endpoints whose name positively identifies the thinking variant (hosted pay-per-token names like databricks-gemini-2-5-pro). This is because ModelClientChatParams carries only model + thinkingEffort — at chat time, GeminiGenerateContentClient must re-derive the variant profile (budget vs level thinking control, ranges, off-ability) from the model string via ai-config's getGeminiGenerateContentProfile.

An external Gemini endpoint named e.g. my-gemini-endpoint backed by gemini-2.5-flash is classified correctly at discovery (the classifier sees external_model.name), but the client would have no way to reconstruct the variant from the endpoint name, so discovery deliberately stamps openai-chat instead (the classifier and client share one helper so stamp and wire choice cannot disagree).

Proposed direction

Widen the chat-params seam so the catalog pipeline can carry a discovery-time profile key (e.g. the resolved underlying model identity or a variant/profile id) into ModelClientChatParams. The client would prefer the carried key and fall back to name-derivation. Cross-repo change: bridge type plus catalog pipeline plumbing in consumers.

Scope notes

• Only worth doing if external Gemini endpoints on Databricks (or similar gateways) matter to users; hosted pay-per-token Gemini already routes natively.
• Could share the seam proposed in Per-protocol capability profiles: overriding a model's protocol should re-derive inferred capabilities #62 (per-protocol capability provenance).