Evaluate supporting DeepSeek as a model provider (from #554)

[tmustier]

Context

In #554, @smryyyyy's fork added default settings for DeepSeek as a model provider, noting it's widely used in China. The PR was closed (personal fork / AI-assisted localisation), but the DeepSeek provider support is worth evaluating independently.

Task

• Review how Pull Request: Add i18n Infrastructure and Chinese (zh-CN) Localization #554 wired up DeepSeek provider defaults
• Decide whether to support DeepSeek as a first-class provider option
• If yes: add default provider config (endpoint, models, auth) + settings UI entry

Notes

• DeepSeek exposes an OpenAI-compatible API, so this may be cheap to support if we already have a generic OpenAI-compatible provider path.
• Separate from the zh-CN localisation question — that would come back as its own Issue + draft PR if the author resubmits with verified translations.

[tmustier]

Resolved — DeepSeek is supported as a first-class provider today:

• Registry: pi-ai 0.80.3 ships deepseek as a builtin provider with deepseek-v4-flash and deepseek-v4-pro in the model registry
• Settings UI: the provider connect list has a DeepSeek row (src/ui/provider-login.ts) using the shared API-key flow (OpenAI-compatible endpoint handled by pi-ai's provider def)
• Default-model logic: since fix: reconcile runtime models when providers change after login #587, pickDefaultModel() treats a configured deepseek provider as a first-class default candidate rather than falling back to OpenAI

No separate endpoint/auth wiring needed beyond what pi-ai provides. The zh-CN localisation question from #554 stays separate as noted.