fix(executors): wire glm and cliproxyapi into the 400 reasoning-effort recovery

[HouMinXi]

Summary

BaseExecutor.execute() carries a reactive 400 clamp-and-retry for a rejected reasoning_effort. Executors that override execute() without calling super.execute() never reach it. #14774 wired commandCode and extracted the shared helper. This PR wires the two remaining executors that actually forward an OpenAI-shaped body carrying reasoning_effort.

• glm.ts calls the helper inside executeTransport, and only on the openai transport. The anthropic transport does not send the field, and the existing transport fallback (isRetryableGlmFallbackStatus) is untouched.
• cliproxyapi.ts calls the helper after its own fetch. The retry reuses the same serializer that drops _toolNameMap and _namespaceToolIdentityMap, so those in-memory maps stay off the wire.

Three executors listed in #14774's Remaining section are left unwired, on purpose:

• ninerouter.ts returns 503 before any fetch when its local supervisor is not running, which is the test environment. The wiring cannot be exercised there.
• gitlab.ts and nlpcloud.ts never reference reasoning_effort. Their upstream bodies are not OpenAI-shaped, so the helper would be dead code.

Related to #14629. #14629 stays open.

Test plan

• tests/unit/issue-14629-remaining-executors-400-recovery.test.ts (2): glm and cliproxyapi each clamp reasoning_effort: "none" to "low" and retry once on a 400 that names the accepted enum
• Defect injection: removing the glm recovery block turned the glm test red while cliproxyapi stayed green; restoring it turned both green
• Existing issue-14629-commandcode-400-recovery-unreachable still passes
• file-size gate clean against upstream/release/v3.8.51