[juliasadler]

Problem

After the chat.qwen.ai frontend upgrade to 0.3.17+, POST /api/v2/chat/completions
fails — first Bad_Request, then Unauthorized — while login / token refresh /
POST /api/v2/chats/new all keep working (#184).

Root cause

Reverse-engineered from the live 0.3.19 frontend bundle (main.js, request
interceptor eX which wraps every request including streams):

1. The frontend force-overwrites Version: 0.3.19 (capital V) on every request.
   This proxy pins version: 0.2.81 in header-profile.js. The stale version
   explains Bad_Request — and matches the reporter's experiment (0.2.81 →
   Bad_Request, 0.3.17 → gets one step further).
2. The frontend sends Authorization: Bearer <accessToken> on every request
   except /auths/refresh. This proxy never sends it (auth relied on the
   token= cookie alone), which explains the remaining Unauthorized.

Notably, the 0.3.19 bundle contains no HMAC request signing at all
(the HMAC strings in main.js are just the bundled sha256 library), and the
__baxia__ token is only used by its own captcha polling — it never enters the
request pipeline. So this is a stale-headers bug, not an anti-bot arms race.

Changes

• src/utils/header-profile.js
  • Add QWEN_WEB_VERSION = '0.3.19' constant (with a comment noting it must
    track the live frontend — it moved 0.3.17 → 0.3.19 within 3 days).
  • 'version': '0.2.81' → 'Version': QWEN_WEB_VERSION in both the legacy
    and fingerprint branches.
  • Add Authorization: Bearer <token> next to the cookie assembly in both
    branches (only when a token is present).
• src/utils/request.js — update stale FE 0.2.81 comments to FE 0.3.19.

Verification

No live Qwen account was available for an end-to-end test, so I verified at
the header level: ran the proxy locally against a mock upstream that records
received headers.

Before the fix, upstream received:
version: 0.2.81, no authorization header.

After the fix, upstream receives:
Version: 0.3.19, Authorization: Bearer <jwt> — matching what the 0.3.19
frontend sends.

Follow-ups (not in this PR)

• Timezone header format differs (UTC+08 vs the frontend's full Date
  string). Left untouched — not implicated by the reporter's experiments.
• Consider fetching the frontend version dynamically instead of pinning it,
  given how fast it moves.