fix(provider): add glm-5.3 to zai_coding provider

[aditzel]

Summary

GLM-5.3 was released on 2026-08-14 and is available to all GLM Coding Plan subscribers (announcement, docs), but it is missing from the hardcoded zai_coding model catalog. This PR adds it.

Changes

• crates/forge_repo/src/provider/provider.json — Added glm-5.3 as the first model under the zai_coding provider, mirroring the existing glm-5.2 entry schema:
  • context_length: 1048576 (1M, per official docs)
  • tools_supported, supports_parallel_tool_calls, supports_reasoning: true
  • input_modalities: ["text"] (GLM-5.3 is text-only)
  • Description notes the 50% coding gain over GLM-5.2, 1M context, 128K max output, and always-on reasoning (low/high/max)

Why only zai_coding and not zai

The GLM Coding Plan endpoint (https://api.z.ai/api/coding/paas/v4) serves GLM-5.3 to all plan tiers now. The general Model API endpoint still lists GLM-5.3 as "available soon" (docs), so the entry is intentionally not added to the zai provider yet.

Notes for reviewers

• z.ai routes requests for glm-5.2/glm-5.1 to GLM-5.3 server-side (devpack docs), so existing users are unaffected; this just makes the real model ID selectable.
• GLM-5.3 does not support disabling reasoning — Forge's thinking transformation for zai providers already always maps reasoning.enabled to thinking: {type: enabled}, which matches the required payload.
• Purely additive JSON change; validated parse + schema parity with the glm-5.2 entry. No existing tests reference zai model lists, so no test changes were needed.

Verification

• provider.json parses cleanly and the new entry uses the identical key set as glm-5.2
• Confirmed GLM-5.3 specs against official docs (1M context, 128K output, text-only, always-on reasoning)
• Confirmed no zai-specific model assertions in provider_repo.rs or integration tests

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.

[aditzel]

Lint Fix failure is pre-existing on main — not caused by this PR

The Lint Fix (autofix.ci) check on this PR fails, but the failure reproduces identically on main itself. This PR only touches crates/forge_repo/src/provider/provider.json and is up to date with main, so it simply inherited the breakage.

Failure

Clippy double_must_use escalated to an error by -D warnings:

error: this function has a `#[must_use]` attribute with no message, but returns a type
already considered as `#[must_use]`

11 unique locations, all in forge_domain:

• crates/forge_domain/src/hook.rs:124
• crates/forge_domain/src/repo.rs:22, 47, 98, 109, 120, 185, 198, 222, 242
• crates/forge_domain/src/result_stream_ext.rs:11

Evidence it's pre-existing

Run	Branch/SHA	Nightly	Result
31225238584	main @ 4c6b68f6 (Aug 7)	1.99.0-nightly (84b36a78a 2026-08-06)	✅ pass
31233723926	main @ 6ed5d37b (Aug 8)	1.99.0-nightly (1a98b1e13 2026-08-07)	❌ fail — same 11 locations
32090104272	this PR (Aug 20)	current nightly	❌ fail — same 11 locations

No relevant code changed between the green and red main runs (only dependency chores: two-face, libsqlite3-sys, diesel, clap_complete). The trigger was the nightly toolchain roll — the autofix workflow uses toolchain: nightly unpinned, so clippy behavior changed overnight.

Root cause

The workspace pins async-trait = "0.1.89" (root Cargo.toml). #[async_trait] generates code that adds #[must_use] to methods returning anyhow::Result<()> — and Result is already #[must_use], so clippy's double_must_use fires on the macro expansion (the errors note: "this warning originates in the attribute macro async_trait").

Upstream fixed this the same day main broke: async-trait 0.1.92 (released 2026-08-08) — "Resolve double_must_use clippy lint in generated code (#303)". The repo is on 0.1.89, so it never picked up the fix.

Suggested fix

Bump the workspace dependency (semver-compatible patch containing exactly this fix):

# Cargo.toml
async-trait = "0.1.92"   # was "0.1.89"

plus cargo update -p async-trait to refresh Cargo.lock.

Optional hardening, separately worth considering:

• Pin the workflow's nightly (e.g. nightly-2026-08-06) so lint behavior can't change under you overnight. Trade-off: you lose new-lint drift detection until you deliberately roll the pin.
• Note rust-toolchain.toml pins stable 1.97 while autofix.ci overrides with unpinned nightly — that's why CI and local stable builds can disagree.

This blocks every PR opened since Aug 8 (mergeable_state: blocked with Build and Test green). Happy to open the one-line bump PR + Cargo.lock update if that's useful — just say the word.