feat(llm): add Atlas Cloud provider preset

[binyangzhu000-sudo]

Summary

Adds an Atlas Cloud entry to PROVIDER_PRESETS so it can be picked in the providers wizard instead of typing the base URL by hand.

Disclosure: I work at Atlas Cloud.

• src/llm/provider/presets/provider-presets.ts: id: "atlas-cloud", baseUrl: "https://api.atlascloud.ai" (no /v1, per the stored-root convention), envVar: "ATLASCLOUD_API_KEY", listsModelsWithoutKey: true. Placed between "Anthropic (Claude)" and "Atomic Chat (local)" to keep the label sort order the existing test enforces. Standard Bearer auth, so no apiKeyHeader / headers.
• src/tui/providers/provider-presets.test.ts: added the preset to the "names every hosted vendor preset after its own service" table and to the keyless-listing presence checks.

Admission bar from provider-presets.ts

Probed 2026-10-10 with the headers the preset sends (plain Authorization: Bearer):

Probe	Result
GET https://api.atlascloud.ai/v1/models, no key	200, data array with 117 entries (branch 1: keyless listing)
POST /v1/chat/completions, bogus key	401 {"code":401,"msg":"unauthorized"}, chat is under /v1 like every other preset (no openai-chat-path.ts entry needed)
bogus paths on the same host: /zzz-bogus, /v1/models/zzz, /v1zzz/models	404
bogus path under the API prefix: /v1/zzz	401 (the /v1 prefix is auth-gated before routing)

The last row is the one place I am not sure the bar is met as you intend it: the host does answer 404 for bogus siblings, but a bogus path directly under /v1 gets the auth 401 rather than a 404. Branch 1 (200 with a data array) does not depend on that, so I read the preset as admissible, but I'm happy to drop it if you read the sibling rule more strictly.

Test plan

• npx vitest run src/tui/providers src/llm/provider: 91 files, 1233 passed, 1 skipped.
• npm run lint, npm run imports:check, npm run docs:check pass; npm run typecheck:tests: no new errors (773 existing debt diagnostics unchanged).
• Live check through the repo's own code, using the preset's baseUrl: fetchOpenAiCompatModels returned the 117 ids without a key, and OpenAiProvider.complete returned the expected reply for deepseek-ai/deepseek-v4-flash, zai-org/glm-5.2 and moonshotai/kimi-k3.
• Not run: the full npm test / test:ci suite and the evals (they need local servers or other paid providers). I ran Node 24.14 rather than the >=25.7 the repo asks for; the commands above passed there.

🤖 Generated with Claude Code

[sosidudku1]

Thanks for the PR, and for the clear disclosure and the probe table. That made this quick to review.

We reran the checks from the admission bar and the endpoint works as described. We are still going to pass on adding it as a preset: the catalog includes Anthropic, OpenAI, Google and xAI models next to the open-weight ones, which puts Atlas Cloud in the routing gateway group, and we made the same call on OrcaRouter in #89. Atlas Cloud users can already connect today through the manual OpenAI-compatible entry in the provider wizard, with base URL https://api.atlascloud.ai.

That said, since you work at Atlas Cloud, we'd be glad to look at other ways to work together. For example: a short "use Atlas Cloud with Atomic Agent" guide, a mention on your integrations page or in your newsletter, or credits for our community to try your open-weight models, with us sharing it on our side. If any of that sounds interesting, drop us a line at nadya@atomicagent.io and we can talk it through.

Closing this PR, with thanks for the careful work.