fix(llm): authenticate Ollama Cloud via OLLAMA_CLOUD_API_KEY + add cloud probe

[VoidChecksum]

Problem

A Discord user on Ollama Cloud (WSL2) is stuck in the Soundwave engagement-planning interview loop on 1.1.3, even after reinstalling. The 1.1.3 changelog fix for the "Soundwave interview loop" only addressed the " (Recommended)" suffix leak (#328) — a different root cause.

The actual bug for Ollama Cloud is an environment-variable name mismatch:

• The onboard wizard (clients/launcher/cmd/onboard.go) and setup docs (docs/setup-guide.md) write the key as OLLAMA_CLOUD_API_KEY.
• The runtime read OLLAMA_API_KEY in config/litellm_dynamic_config.py and the cloud model resolver.

Nothing connected the two (grep confirms: OLLAMA_CLOUD_API_KEY was only ever written, never read). So a user who completes decepticon onboard for Ollama Cloud sends an empty Bearer token to https://ollama.com/v1 → 401 on every turn → the agent never advances past the Soundwave interview = "stuck in the loop."

Fix

1. Key mismatch (the loop) — read OLLAMA_CLOUD_API_KEY first, fall back to OLLAMA_API_KEY (the official Ollama convention), in:

• config/litellm_dynamic_config.py (Bearer auth wiring)
• packages/decepticon-core/.../types/llm.py (_resolve_ollama_cloud_model)
• packages/decepticon/.../llm/factory.py (_ollama_cloud_configured opt-in — now consistent with the resolver, which already treated the key as an opt-in signal)

No existing setup breaks; the wizard/docs already use the _CLOUD_ form, which now works.

2. Cloud tool-capability probe — the startup probe (config/ollama_probe.py / litellm_startup.py) only ever ran against local Ollama (OLLAMA_API_BASE, host.docker.internal). A cloud-only user (empty local base) short-circuited on "OLLAMA_API_BASE is empty" and got no cloud diagnostic. Added:

• probe_cloud() — Bearer-authenticated reachability + /api/show capability check, targeting the native API root (strips the OpenAI-compat /v1 path).
• Local/cloud prefix separation so litellm_startup probes each family independently.
• Clear remediation lines for a missing key (401) or a non-tool-capable cloud model at boot.

Out of scope (flagged, not changed)

The default cloud model _OLLAMA_CLOUD_DEFAULT_MODEL = "llama3.2" (llm.py) isn't a real Ollama Cloud model — a user who sets base/key but omits OLLAMA_CLOUD_MODEL will 404. The new probe now surfaces this, but the default itself is left unchanged pending a maintainer decision.

Immediate workaround (for affected users, no rebuild)

Edit ~/.decepticon/.env:

OLLAMA_API_KEY=<same value as OLLAMA_CLOUD_API_KEY>
OLLAMA_CLOUD_API_BASE=https://ollama.com/v1
OLLAMA_CLOUD_MODEL=qwen3-coder:480b   # a real tool-capable cloud model, not the llama3.2 default

then decepticon restart.

Verification

• +8 unit tests (key precedence, prefix filtering, native-base normalization, probe_cloud auth/401/capability).
• Full tests/unit/llm/ + test_auth.py suites: 234 passed, 2 skipped (Windows-only).
• ruff check clean; basedpyright 0 errors/0 warnings.

🤖 Generated with Claude Code