Z.AI API Integration and GLM Model Support

What problem is this feature trying to solve?

Currently, PAL MCP Server supports multiple providers, but Z.AI is not available as a first-class provider despite prior implementation work.

There is already a closed PR with most of the groundwork:

• https://github.com/BeehiveInnovations/pal-mcp-server/pull/310

There is also direct user demand for this capability:

I would love to be able to add z.ai with an api key. (Glm 4.5 and 4.6)
Originally posted by @thinkbig1979 in #198

Without native Z.AI support, users cannot configure GLM models through the standard provider flow and must rely on workarounds.

Describe the solution you'd like

Resurrect and modernize PR #310 by implementing Z.AI as a registry-backed native provider (matching current architecture patterns, e.g. X.AI provider style), including:

• ProviderType.ZAI support
• providers/zai.py using OpenAI-compatible base with Z.AI Coding API endpoint
• providers/registries/zai.py
• conf/zai_models.json with GLM model metadata and aliases
• server/provider registry wiring:
  • ZAI_API_KEY detection
  • provider registration in startup flow
  • provider priority order integration
  • API key mapping for provider instantiation
• allowlist/restriction support:
  • ZAI_ALLOWED_MODELS

Initial target models:

• glm-4.6 (required)
• optionally glm-4.5 if still available/supported by Z.AI API

Expected outcome: Users can set ZAI_API_KEY and use Z.AI models in the same way as existing native providers.

Describe alternatives you've considered

• Using Custom/OpenAI-compatible provider manually with Z.AI endpoint.
  • Works partially, but lacks first-class model registry, aliases, provider-specific restrictions, and consistent UX.
• Keeping PR #310 as-is.
  • Not ideal, since it predates the current registry-backed provider pattern and includes extra docs/scripts not aligned with current provider conventions.

Feature Category

Integration enhancement

Additional context

I'm using PR #310 as the baseline reference but aligning implementation to current codebase standards (registry-backed providers, capability JSON manifests, and existing provider wiring conventions etc)