Add Z.AI (GLM) provider; restore workspace build

[YASSERRMD]

Summary

Validated the multi-provider path against a live GLM (Z.AI) endpoint, and folds in the fixes that work surfaced.

Live validation (not committed; key supplied for testing only)

• A real glm-5.1 completion flowed end-to-end through OpenAiCompatibleProvider against https://api.z.ai/api/coding/paas/v4, on both the direct path and the ProviderRegistry::get_providers -> complete path the planner uses. Response content, token usage, and latency parsed correctly.
• Confirmed Z.AI's response shape (choices[].message.content, usage.total_tokens) matches the client.

Changes

• zai provider added to the catalog (Z.AI / Zhipu international GLM, OpenAI-compatible, ZAI_API_KEY, base https://api.z.ai/api/paas/v4; coding-plan keys use /api/coding/paas/v4). Documented in docs/model-providers.md and .env.example, with a unit test.
• gateway build fix: declare the tower-http dependency it already imports (CorsLayer). This was a pre-existing break that stopped cargo build --workspace.

Verification

• cargo test -p clawforge-planner and -p clawforge-controlplane pass (90 tests total).
• cargo build --workspace now succeeds.

Note on cargo test --workspace

Three unrelated crates (clawforge-cli, clawforge-memory, clawforge-scheduler) have pre-existing stale test fixtures (new Capabilities/AgentSpec fields and renamed clawforge_memory exports) that fail to compile under cargo test. Their libraries build fine. Repairing those fixtures is a separate, focused cleanup and is intentionally not bundled here.