fix(provider): apply reasoning_effort to ZAI providers via SetZaiThinking

[tmchow]

Summary

Apply :reasoning-effort to z.ai providers (GLM 5.1 et al). Today the user can run :reasoning-effort none or :reasoning-effort high against GLM 5.1 and observe no behavior change because the per-effort setting is silently dropped before the request reaches the z.ai pipeline. This PR threads the user's intent through to z.ai's thinking: {type: enabled|disabled} shape.

Importance

z.ai's API only exposes thinking as on/off ({"type": "enabled"|"disabled"}), but Forge's internal model maps :reasoning-effort to Effort::None|Minimal|Low|Medium|High|XHigh|Max. Two pieces of code were dropping the user's intent:

1. crates/forge_app/src/dto/openai/transformers/pipeline.rs:62-67 gates SetReasoningEffort on REQUESTY | GITHUB_COPILOT | deepseek | NVIDIA. ZAI is excluded by design (z.ai doesn't accept reasoning_effort), so its parallel transformer SetZaiThinking is the only path that should be touching reasoning for these providers.
2. crates/forge_app/src/dto/openai/transformers/zai_reasoning.rs only mapped reasoning.enabled to thinking. The user's :reasoning-effort setting reaches the request as reasoning.effort with enabled: None, so SetZaiThinking did nothing and the request shipped without thinking. GLM 5.1 defaults to thinking ON, so the user got no behavior change for either none or high.

The Effort::None path additionally triggered an upstream short-circuit: Context::is_reasoning_supported() (crates/forge_domain/src/context.rs:644-647) treats Effort::None as a strong opt-out, after which DropReasoningDetails (gated at crates/forge_app/src/orch.rs:209) wiped the entire reasoning config before SetZaiThinking ever ran.

Closes #3074

Testing

• cargo test -p forge_app zai_reasoning -> 13 tests pass (8 existing + 5 new effort-coverage tests)
• cargo test -p forge_app drop_message_reasoning -> new transformer test passes
• cargo test -p forge_app -> full crate suite passes
• cargo clippy -p forge_app --all-features --all-targets -- -D warnings -> clean
• cargo clippy --all-features --workspace -- -D clippy::string_slice -D clippy::indexing_slicing -D clippy::disallowed_methods -> clean

This contribution was developed with AI assistance.

[laststylebender14]

What about other reasoning fields?

[tmchow]

I scoped this to reasoning_details to match the sibling DropReasoningDetails transformer in forge_domain (clears reasoning_details + context.reasoning only). The other reasoning-adjacent field on TextMessage is thought_signature, which only flows through dto/google/response.rs and is left alone by the sibling. Happy to clear it too if you'd prefer cross-provider parity here, just wanted to flag the scope intentionally matched the sibling before broadening.

[amitksingh1490]

this should be done at request layer as its zai specific change, not at context layer.
This layer should have changes which is needed by most of the provider implementation

[tmchow]

@laststylebender14 thanks for the review.

you don't need to pass provider from here, you can directly access it as it's avail on self.

Fixed in 5f5f14d. Method now reads let provider_id = &self.agent.provider; internally so the body keeps the same shape.

What about other reasoning fields?

I scoped this to reasoning_details to match the sibling DropReasoningDetails transformer in forge_domain (clears reasoning_details + context.reasoning only). The other reasoning-adjacent field on TextMessage is thought_signature, which only flows through dto/google/response.rs and is left alone by the sibling. Happy to clear it too if you'd prefer cross-provider parity here, just wanted to flag the scope intentionally matched the sibling before broadening.

[github-actions]

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

[tmchow]

@laststylebender14 lmk if there's anything else!