fix(qwen-oauth): add follow_redirects=True and diagnostic logging

[wjgong001]

Summary

Fixes #7746

Root Cause

httpx defaults to follow_redirects=False (unlike requests which follows by default). The Qwen OAuth token endpoint returns a redirect response (302), which httpx returns as-is — an empty body with no JSON. response.json() then fails with:

Expecting value: line 1 column 1 (char 0)

This explains the same-machine, same-creds asymmetry: qwen-code-api uses requests which follows redirects automatically.

Changes

1. follow_redirects=True on the httpx.post call — lets httpx follow the redirect and get the actual JSON response from the Qwen OAuth endpoint
2. Diagnostic logging before JSON parsing — logs status_code, content-type, content-length, and location header whenever the response looks non-JSON. This makes future OAuth issues easier to debug without adding a Qwen-style User-Agent dependency.

Test Plan

• Run hermes provider auth qwen-oauth against a valid Qwen CLI credential file
• Confirm token refresh succeeds
• Check gateway log for diagnostic messages

[teknium1]

Thanks for tracking this down. The underlying bug still appears to exist on current main, but this branch needs narrowing before it is safe to salvage.

Problems

• Current main still posts Qwen refresh requests without follow_redirects=True in hermes_cli/auth.py:2011-2023, then parses JSON at hermes_cli/auth.py:2040-2047. That matches the reported invalid-JSON failure path when the endpoint returns a redirect or other empty/non-JSON body.
• The PR diff is much broader than the Qwen fix: gh pr diff 28244 --patch shows 1016 additions / 103 deletions in hermes_cli/auth.py, including unrelated Nous scope/JWT changes, xAI loopback/token-exchange changes, Azure Foundry auth status, and MiniMax quarantine logic. That makes the patch risky to take as-is.
• Existing Qwen tests cover success/error/invalid JSON in tests/hermes_cli/test_auth_qwen_provider.py:183-263, but none assert that the refresh request follows redirects or that the new diagnostics fire for non-JSON responses.

Suggested changes

• Keep only the Qwen-specific change in _refresh_qwen_cli_tokens: follow_redirects=True plus narrowly scoped diagnostics.
• Add a focused regression test asserting httpx.post(..., follow_redirects=True) for Qwen refresh, and a diagnostic-path test if the logging stays.

This is an automated hermes-sweeper review; a human maintainer can decide whether to cherry-pick the focused Qwen hunk.

[teknium1]

Thanks for tracing the Qwen refresh path. The underlying issue remains present on current main: hermes_cli/auth.py:2294-2306 posts the Qwen refresh request without follow_redirects=True, and hermes_cli/auth.py:2323-2330 then parses the response as JSON.

Problems

• Commit b14526143353d96359a332356ca33eb6723be449 is far broader than this fix: its sole-file diff is +1016/-103 in hermes_cli/auth.py, including unrelated Nous, xAI, Azure Foundry, and MiniMax auth changes. Please keep the salvage limited to the Qwen refresh hunk.
• There is no regression test for the new request option. tests/hermes_cli/test_auth_qwen_provider.py:183-200 mocks httpx.post but does not assert its arguments; the PR changes no test files.

Suggested changes

• Retain only the Qwen-specific follow_redirects=True change (and narrowly scoped diagnostics if desired) in _refresh_qwen_cli_tokens.
• Add a focused assertion that the refresh call passes follow_redirects=True, plus diagnostic-path coverage if that logging remains.

This is an automated hermes-sweeper review.

[teknium1]

Please add a focused regression assertion in tests/hermes_cli/test_auth_qwen_provider.py that httpx.post receives follow_redirects=True; the existing success test verifies returned tokens but not the request options.