Require explicit -k API key, add Ollama / Ollama‑Cloud handling, update docs

[hellocodelinux]

Summary:

• Modified compose behavior to remove environment-variable fallback for API keys: authenticated services must be provided an API key via -k/--api-key.
• Added clearer separation between ollama (local, no auth) and ollama-cloud (cloud models via local Ollama client, requires -k).
• Implemented native Ollama payload/response handling (endpoint: http://localhost:11434/api/chat).
• Added --api-url override for custom endpoints.
• Fixed send_request to only add Authorization when an api key is present.
• Updated documentation (doc/AUTOCOMPOSE.md): command examples, model examples (local Ollama -> gemma3, Ollama Cloud -> kimi-k2:1t-cloud), and fenced command blocks so examples render correctly.

Rationale:

• Requiring -k simplifies authentication logic and avoids ambiguity from multiple fallbacks. It is also explicit and easier to audit in CI / config files.
• Separating ollama vs ollama-cloud avoids incorrect assumptions about auth and endpoint/formats.
• Native Ollama support fixes Method Not Allowed / response-parsing issues when using the local Ollama client.

Testing
Please run these quick checks locally:

# local Ollama (no API key required)
./src/compose -s ollama -m gemma3 -c doc/example-history.txt

# Ollama Cloud via local client (requires -k)
./src/compose -s ollama-cloud -k "your-ollama-cloud-api-key" -m kimi-k2:1t-cloud -c doc/example-history.txt

# OpenAI (requires -k)
./src/compose -s openai -k "sk-your-api-key" -m gpt-4o -c doc/example-history.txt

Notes / items for reviewer

• Please review src/compose changes for any preferred error messaging or behavior differences.
• Consider whether we want to keep -k strictly required for authenticated services or support a priority order (CLI -k > env var). I removed env var support per request, but can reintroduce a fallback if you prefer.
• Confirm the Ollama native payload/response format meets expectations for other local deployments.

If you’re happy with this approach, merge as-is. If you prefer env-var fallback or a different CLI UX for keys, say so and I will adjust.

[d99kris]

Thanks for contributing (again)! 🙂

One concern with requiring API key as command-line argument is that they are frequently visible to other users on the same system (e.g. via ps, /proc, activity monitor) and when manually testing they end up in shell history. That makes it a risky method to pass secrets.

Using an environment variable (or a dedicated secrets store/config file) is a more common practice for command line tools handling API keys, because it reduces accidental disclosure.

Based on this I propose not requiring explicit -k API key argument. I'm still open to consider some of the other improvements suggested (but I'd prefer an updated patch to review). Thanks!