…tation

- Add Qwen (DashScope) as provider #34 with intl/us regions
- Add MiniMax as provider #35 with china region (separate API key)
- Add provider_regions to configuration reference table and example
- Add Provider Regions section under Dynamic Provider Loading

…tation

- Add Qwen (DashScope) as provider #34 with intl/us regions
- Add MiniMax as provider #35 with china region (separate API key)
- Add provider_regions to configuration reference table and example
- Add Provider Regions section under Dynamic Provider Loading

* feat: add Qwen International and US provider endpoints

Add qwen-intl (Singapore) and qwen-us (Virginia) as separate providers
so international users can select the correct regional endpoint.
Aliases: dashscope-intl, qwen-sg, dashscope-us.

Fixes #1328

* docs: move Qwen regional endpoints to own section and update create_driver doc-comment

Move QWEN_INTL_BASE_URL and QWEN_US_BASE_URL constants out of the
"Chinese providers" section into a new "Qwen regional endpoints"
section, since these endpoints serve non-China regions.

Add qwen, qwen-intl, and qwen-us to the supported providers list
in the create_driver doc-comment.

* Revert "docs: move Qwen regional endpoints to own section and update create_driver doc-comment"

This reverts commit fef2edd.

* feat: add RegionConfig for provider multi-region support

Add RegionConfig struct with base_url and optional api_key_env to
support providers with regional endpoints (e.g. Qwen China/Intl/US,
MiniMax China/International). Add provider_regions config to select
active region per provider. Remove catalog/ directory (migrated to
librefang-registry repo).

* feat: show provider regions in dashboard settings

* fix: propagate region api_key_env to provider_api_keys

resolve_region_urls() only extracted base_url, silently dropping
api_key_env from RegionConfig. This meant regions with custom API key
env vars (e.g. minimax china with MINIMAX_CN_API_KEY) would get the
correct URL but still use the wrong API key.

Add resolve_region_api_keys() that extracts api_key_env overrides,
and apply them in kernel init via config.provider_api_keys (lower
priority than user-explicit entries).

* docs: add provider_regions examples to config and env templates

* docs: add Qwen/MiniMax provider sections and provider_regions documentation

- Add Qwen (DashScope) as provider #34 with intl/us regions
- Add MiniMax as provider #35 with china region (separate API key)
- Add provider_regions to configuration reference table and example
- Add Provider Regions section under Dynamic Provider Loading

* feat: expose provider regions in API and CLI templates

- Add GET /api/providers/{id}/regions endpoint
- Include active_region in provider API response
- Add provider_regions section to CLI init templates

* fix: hot-reload provider_regions + warn invalid regions + fix tests

- config_reload: detect provider_regions changes for hot-reload
- kernel: replicate boot-path region logic in hot-reload handler
- model_catalog: add resolve_region_api_keys(), warn on unknown
  providers/regions, replace vacuous tests with synthetic catalog
- config: add provider_regions TOML roundtrip test

* fix: repair test failures in region catalog and provider count

- Add missing supports_streaming field to synthetic test TOML
- Fix tier enum casing (Smart→smart, Fast→fast) in test TOML
- Restore minimax-cn as valid provider in model alias assertions
- Update provider count assertion after minimax-cn removal

**CI (#17, #28, #55)**: move `corepack enable` to run AFTER
`actions/setup-node` in all four workflows (deploy-web, deploy-docs,
lighthouse, test-web). Corepack shims are installed into whichever
Node lives on PATH at the time; running it first means setup-node
later switches to a different Node install that lacks the shims,
causing intermittent `pnpm: command not found` failures.

**Web (#34)**: registry detail page now tries both MCP manifest
layouts — flat `mcp/<id>.toml` (legacy, still the majority) and
directory-backed `mcp/<id>/MCP.toml` (new, multi-file packages) —
matching what `web/scripts/fetch-registry.ts` already accepts. The
resolved path (whichever candidate returns 200) is what the
"View on GitHub" and commit-history lookups use, so those links
always point at the file the user is actually viewing.

Extracted `pathCandidatesFor` and `fetchFirstAvailable` into
`web/src/lib/registry-raw.ts` so the list page's hover-prefetch
and the detail page's real fetch share one cache entry and one
source of truth for path layout. Dropped the redundant
`fileNameFor` field from `CATEGORY_META` — it duplicated the
same knowledge.