feat: first-class glm/zhipu provider alias + model-name inference

[mvanhorn]

Summary

This adds a first-class glm provider alias of the existing zhipu provider, plus model-name inference, so GLM / Zhipu coding-plan users no longer have to borrow the openai slot. When the model name starts with glm, the agent now resolves the Zhipu provider and its base URL automatically even if no explicit provider is configured.

Why

This closes #237, where a user asked for first-class GLM / Zhipu support and you confirmed that a dedicated glm / zhipu alias, so people do not have to borrow the openai slot, would be a very welcome PR, pointing at the provider layer.

The problem today is silent and confusing. A zhipu provider already exists, but there is no glm alias and nothing that infers the provider from the model name. So a user who sets only their model to glm-4.6 or glm-5.1 falls through to the OpenAI capability record and gets pointed at the OpenAI base URL, with no error to explain why their GLM key is being ignored. Making glm a real alias and teaching the inference path about it removes that footgun and matches what the issue actually asked for.

Changes

The change follows the existing kimi to moonshot alias precedent exactly. The Zhipu capability record is now shared between the canonical zhipu provider and the new glm alias, the model-name inference path maps any glm-prefixed model back to Zhipu, and the provider registry gains a glm entry that reuses the same Zhipu environment variables and default model so onboarding and diagnostics surface it. Tests cover the alias, both glm-4.6 and glm-5.1 inference, the environment-name resolution, and confirm that an unknown or empty model still falls back to OpenAI.

Two things are deliberately left out of scope. Coding-plan-specific request headers are not added here, because those need the exact 400 payload from the coding endpoint and a separate shape decision, the same situation as the Kimi For-Coding work in #204. The alias is also not added to the CLI status and choice maps, since the canonical zhipu already covers those displays, mirroring how kimi defers to moonshot there.

Test Plan

• New capability and inference tests pass (the TestProviderCapabilityAliases class plus the provider-defaults regression, 9 passing).
• ruff check is clean on the changed files.

The build_llm tests that import the optional langchain-openai dependency were not run here because it is not installed in this environment; the same five errors are present on a pristine main checkout, so they are pre-existing and unrelated to this change.

Checklist

• No changes to protected areas without prior discussion; the provider-layer change is the one you invited in the issue.
• No hardcoded values beyond the existing provider-registry conventions.
• Code follows CONTRIBUTING.md, including the DCO sign-off on the commit and Google-style docstrings.
• No README provider-list change is needed because GLM is an alias of the already-listed Zhipu provider.

Fixes #237

[mvanhorn]

Thanks for merging this, @warren618. A first-class glm alias for the zhipu provider plus model-name handling is a nice convenience.

[mvanhorn]

Thanks @warren618 - the first-class glm alias plus model-name inference means GLM/Zhipu users no longer have to borrow the openai config.