Direction request: direct official DeepSeek API provider

[shteudguy]

Would a default-disabled direct-API provider fit T3's provider architecture, or should this remain a downstream extension?

The implementation is concrete: one provider package plus registry, protected settings, client metadata and mobile setup wiring. It uses the official SSE API and T3's runtime policy; it does not require installing another CLI. It owns a small agent/tool loop and durable journal, which is the architectural difference from the existing DSH/ACP route that needs your decision.

Supported scope is streaming text/reasoning, native tools, Stop, steering, handoff and safe fresh-session recovery. Unsupported structured Plan requests fail before prompting. Context is bounded without deleting the transcript or replaying completed tools. A recognized stream loss has a finite retry; unavailable usage is marked partial.

There are 45 changed files on pinned e455. Local patches and focused evidence are prepared. Prior support for DSH in #7331/#11937 and the registry approach in #32943 do not approve this direct-API design, so I am asking about direction before submitting the implementation PR.

If the direction is useful, what scope and split would you want for review? If the shared ACP path is the intended boundary, I will retain the direct-API implementation downstream.

Source branch: https://github.com/shteudguy/t3code/tree/feat/deepseek-api-e5 (ca82188).