Improve OpenClaw provider alias migration compatibility

[NextDoorLaoHuang-HF]

Summary

• improve OpenClaw -> OpenFang provider migration compatibility across aliases and custom provider catalogs
• fix local-provider env mapping regression by keeping explicit VLLM_API_KEY / LMSTUDIO_API_KEY
• harden models.providers-aware migration so custom providers only pass through when runtime routing is valid
• add integration coverage for JSON5 catalog-driven provider resolution edge cases

What changed

• provider alias mapping in OpenClaw migration covers additional aliases such as:
  • qwencode -> qwen
  • kimicode -> moonshot
  • copilot -> github-copilot
  • dashscope -> qwen, kimi -> moonshot, glm -> zhipu, baidu -> qianfan
• when models.providers metadata exists, migration now:
  • resolves provider using api hints (e.g. anthropic-messages, openai-completions)
  • carries baseUrl into generated config.toml and agent model blocks
  • preserves custom provider IDs only when base_url exists (so runtime can route custom provider safely)
  • falls back to known provider IDs when custom IDs would otherwise be invalid (unknown provider + no base_url)
  • supports alias/canonical key mismatch lookup between model refs and provider catalog keys (e.g. gpt/... with providers.openai)
• local providers keep explicit env names where needed:
  • vllm -> VLLM_API_KEY
  • lmstudio -> LMSTUDIO_API_KEY

Tests

• cargo test -p openfang-migrate ✅
• new/expanded integration tests:
  • crates/openfang-migrate/tests/provider_json5_default_model.rs
  • crates/openfang-migrate/tests/provider_json5_agents.rs
  • crates/openfang-migrate/tests/provider_json5_provider_catalog.rs
  • crates/openfang-migrate/tests/provider_legacy_yaml.rs
• new unit coverage in openclaw.rs for catalog edge cases:
  • unknown custom provider without baseUrl
  • alias canonicalization (gpt/claude/grok)
  • alias/canonical catalog key mismatch resolution

Why

OpenClaw migrations with provider aliases/custom IDs could produce unstable outputs in edge cases, especially around provider catalogs and OpenAI-compatible custom endpoints. This patch reduces post-migration manual fixes and avoids generating runtime-invalid provider configs.

Related to #116