feat(pi): add DeepSeek provider support

[zengdard]

Summary

Register DeepSeek as a runtime provider in the Pi SDK when DEEPSEEK_API_KEY is set, enabling deepseek/deepseek-* models to be used directly without the Vercel AI Gateway.

Changes

• packages/processor/src/agents/pi-sdk.ts: In createPiSession(), detect DEEPSEEK_API_KEY and register the deepseek provider with configurable base URL (DEEPSEEK_BASE_URL, defaults to https://api.deepseek.com/v1).

Usage

export DEEPSEEK_API_KEY=sk-xxx
deepsec scan . --model deepseek/deepseek-v4-flash

Context

DeepSeek models use the OpenAI-compatible API format, so api: "openai-completions" is used. The provider registration follows the same pattern as the existing Anthropic and OpenAI handling.

Closes #—

[vercel]

@zengdard is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[zengdard]

Hi can you accept it ? or review it ?

BR,

[zengdard]

Great feedback, thanks @richardchen874-sys! To answer your question: the primary intent here is cost reduction with provider-agnostic throughput — DeepSeek's OpenAI-compatible API makes it a drop-in replacement so teams can route broad-pass scans at a fraction of the cost, and the PR intentionally keeps it a runtime registration (not a config toggle) so the existing deepsec pipeline stays unchanged.

Agreed on tracking phase/model/latency/usage/finding quality separately — that's exactly the right split, and it's what would make a proper cost-aware routing layer viable (cheap models for the wide pass, stronger models for severity mapping). This PR is intentionally scoped to just the provider registration; a follow-up routing layer that scores per-phase quality vs. cost would be a natural next step, and your multi-model API layer sounds complementary to it. Happy to collaborate on that if you're interested.