Summary

This PR addresses issue #216 (Alibaba Bailian / DashScope compatibility: 405 Method Not Allowed when validating/using OpenAI-compatible endpoints in MicroClaw).

The likely provider-side gating condition in this case is that MicroClaw was sending some LLM-related HTTP requests without an explicit User-Agent, while OpenClaw and other interactive clients typically send a product-identifying UA.

This change adds a consistent User-Agent for MicroClaw OpenAI-compatible call paths and makes it overrideable for provider-specific troubleshooting.

Root Cause

MicroClaw OpenAI-compatible request paths used reqwest::Client::new() in several places, which did not set an explicit MicroClaw UA string:

• runtime LLM chat calls (src/llm.rs)
• setup online validation calls (src/setup.rs)
• /models api provider listing calls (src/chat_commands.rs)

In contrast, OpenClaw codebase patterns include explicit User-Agent usage across many network call paths.

Changes

1. Added a shared helper in src/http_client.rs:

   • llm_user_agent() returns:
     • env override: MICROCLAW_LLM_USER_AGENT when set and non-empty
     • default: MicroClaw/<version> (+https://github.com/microclaw/microclaw)

2. Wired this UA into OpenAI-compatible related call paths:

   • OpenAiProvider HTTP client in src/llm.rs
   • setup validation blocking client in src/setup.rs
   • models API clients in src/chat_commands.rs (both anthropic and openai-compatible listing paths)

3. Exported new module via src/lib.rs.

4. Added tests for default and override UA behavior in src/http_client.rs.

Validation

• cargo fmt
• cargo test -q llm_user_agent

Impact

• Improves compatibility with providers that expect/require non-empty client user-agent identification for interactive usage policy checks.
• Keeps behavior flexible via MICROCLAW_LLM_USER_AGENT for fast provider compatibility testing.

Closes #216