Add Atlas Cloud provider preset

@binyangzhu000-sudo is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

I went to resolve the conflicts with main and concluded this should be closed instead. main grew a general mechanism that covers exactly what this PR hardcodes.

When this was opened, wiring a non-gateway OpenAI-compatible endpoint meant adding a named preset. Since then you shipped the ModelRoute layer (mode: "gateway" | "direct" | "custom" | "local"), and configureProviderOverrides now handles any provider generically — cfg.aiProvider, cfg.aiBaseUrl, and cfg.aiCredentialHeader + cfg.aiApiKeyEnv all flow through without the provider needing to be known ahead of time.

docs/models.md documents this with Martian, which is the same shape of thing as Atlas Cloud:

pnpm deepsec setup --project-id my-app \
  --agent pi \
  --model openai/gpt-5.5 \
  --model-auth custom \
  --ai-provider martian \
  --ai-base-url https://api.withmartian.com/v1 \
  --ai-api-key-env MARTIAN_API_KEY \
  --ai-credential-header authorization:bearer

Atlas Cloud works the same way today, with no code change:

ATLASCLOUD_API_KEY=...
pnpm deepsec setup --project-id my-app \
  --agent pi \
  --model openai/deepseek-ai/deepseek-v4-pro \
  --model-auth custom \
  --ai-provider atlascloud \
  --ai-base-url https://api.atlascloud.ai/v1 \
  --ai-api-key-env ATLASCLOUD_API_KEY \
  --ai-credential-header authorization:bearer

One thing I checked before writing this off, since it was the one plausible gap: my branch set api: "openai-completions" on the provider override, and the generic path doesn't set api at all. But the Martian example passes --model openai/gpt-5.5 — the model-name prefix is what selects the wire protocol, so the generic path doesn't need it. No gap.

That leaves this PR as a named alias for a flow that already works, plus a baked-in model id — against a registry you've deliberately kept provider-agnostic. Not worth the maintenance, and rebasing it across the 18 commits of drift would just be re-litigating your Martian decision.

Happy to close it myself, or you can close it directly.

Disclosure: I work at Atlas Cloud — which is exactly why I'd rather retire this than argue for a preset carrying our name.

I went to rebase this and stopped, because the conflicts are the symptom rather than the problem. Reporting what I found instead of pushing a resolution.

main already has the generic mechanism this PR special-cases. PiAgentConfig now carries aiProvider, aiBaseUrl, aiApiKeyEnv, aiHeaders and aiCredentialHeader, all persisted through config, and configureProviderOverrides applies them to any provider name. There are no Atlas references anywhere in main. So Atlas Cloud is already reachable with the built-in path — it's a plain OpenAI-compatible host at https://api.atlascloud.ai/v1 with Authorization: Bearer, no custom header or request shape — and what this PR adds on top is an ATLAS_PROVIDER branch that hardcodes one model id, display name, context window and price table.

That hardcoded catalog entry has already gone stale, which is the concrete argument against carrying it. The PR pins:

cost: { input: 1.68, output: 3.38, cacheRead: 0.13, cacheWrite: 0 }

Atlas currently publishes, from its own /api/v1/models:

"input_price": "1.32", "output_price": "3.96", "cache_price": "0.132"

Both input and output are wrong now, and output is wrong in the direction that under-reports cost. A price table in someone else's repo can't track a vendor's pricing, so this would keep drifting.

The conflicts themselves are minor and I could resolve them — upstream renamed configurePiProviders to configureProviderOverrides and added gateway attribution headers — but resolving them would just preserve the part that shouldn't land.

So my recommendation is to close this. Happy to do it myself, or leave it to you. If a curated per-provider catalog is something you do want eventually, the right shape is probably fetching it from the provider at runtime rather than pinning it in source, and I'd be glad to send that as a separate proposal if you're interested.