chore: show Unity Catalog model names in the chat composer

[kalvinnchau]

Category: fix
User Impact: Databricks users can read the model name in the chat composer without catalog and schema prefixes obscuring it.

Problem: Unity Catalog models arrive as fully qualified $catalog.$schema.<model> identifiers, so the narrow composer picker truncates the most important final segment. Persisted selections and pre-discovery fallback labels could also continue showing the qualified identifier.

Solution: Keep the canonical identifier for selection and search while deriving composer-facing labels from the final model segment. Apply the same formatting to discovered options, direct ID fallbacks, and previously persisted qualified display names.

File changes

src/features/providers/lib/modelRecommendations.ts
Centralizes model-label derivation and strips the catalog/schema prefix from discovered Databricks Unity Catalog identifiers while preserving canonical IDs.

src/features/providers/lib/modelRecommendations.test.ts
Covers the discovered Unity Catalog option label and verifies the full ID remains intact.

src/features/chat/lib/modelDisplayLabel.ts
Uses model-only labels for composer fallbacks and repairs persisted qualified labels before inventory is available.

src/features/chat/lib/modelDisplayLabel.test.ts
Covers direct Unity Catalog selections, persisted labels, and non-Databricks behavior.

[morgmart]

🤖 Automated code review

APPROVE. Fresh static review of the exact three-dot comparison c2fca34...3a78e36 found no publishable findings. The changed display-label derivation preserves canonical model IDs while consistently shortening Databricks Unity Catalog labels across discovered options, direct-ID fallback, and persisted qualified names; focused tests cover those paths and non-Databricks preservation. Final self-check covered every changed user flow; accessibility; i18n/localization completeness; navigation and consent guards; async, error, never-completes, lifecycle, and race behavior; test honesty; design-system/project rules; duplicate/overlapping findings; and concrete evidence plus user effect for blocking severity. No unsupported or overlapping findings survived. Supplied GitHub evidence was inspected: DCO and clean-room install passed, frontend and three Tauri checks were still in progress, and one close job was skipped; required checks still govern merge readiness.

Deterministic publication result: 0 blocking and 0 non-blocking finding(s) publishable; 0 duplicate(s) suppressed.

Pending checks: 5 check(s) are not complete.

This approval reflects the completed code review only; merge readiness remains governed by the repository's required checks.