[Zartharas]

Summary

Fix Z.ai web connection testing so it validates the Local Storage session token against Z.ai's authenticated user-settings endpoint instead of relying on the generic /api/models web-session probe.

The dedicated validator preserves literal upstream status codes so callers can distinguish an exact authentication rejection from rate limits, server errors, and other upstream failures.

Root cause

zai-web previously fell through to the generic web-cookie validator.

That path probes /api/models, which is primarily a model-catalog endpoint rather than a dedicated authenticated-session endpoint. It also uses the generic AUTH_007 handling instead of returning the precise upstream status needed by connection-test failure classification.

Z.ai's current OmniRoute credential contract stores only the Local Storage token, so the validator needs to test the same token-only authentication shape used by the provider.

Fix

Added a dedicated validateZaiWebProvider() that:

• extracts the existing Z.ai Local Storage token using extractZaiToken()
• sends GET /api/v1/users/user/settings
• authenticates using only Authorization: Bearer <token>
• does not require or send a Cookie header
• treats 2xx as valid
• preserves exact HTTP 401 as invalid/expired credentials
• preserves 403 without labeling it as an expired session
• preserves 429 and 5xx status codes for downstream classification
• does not consume the upstream response body

The specialty validator is registered ahead of the generic web-session fallback.

Live semantic verification

A read-only control was performed before implementation:

• valid current Z.ai Local Storage token → HTTP 200
• fixed synthetic invalid token → HTTP 401
• Cookie header sent → no
• response body read → no
• provider mutation → none
• OmniRoute mutation → none

This confirmed that /api/v1/users/user/settings provides a reliable token-only authentication signal for the credential format OmniRoute actually stores.

Validation

Focused new regression:

• tests/unit/zai-web-auth-semantics.test.ts — 4/4 passed

Existing web-validation regressions:

• provider-validation-web-cookie-auth007.test.ts
• web-cookie-validation-proxy-7058.test.ts
• 6/6 passed

Existing Z.ai executor suite:

• executor-zai-web.test.ts
• 28/28 passed

Additional gates:

• focused ESLint — passed
• npm run typecheck:core — passed
• git diff --check — passed

No live OmniRoute stack was modified during implementation.

[diegosouzapw]

Thanks for this — the root cause is spot on: zai-web was falling through to the generic /api/models catalog probe with generic AUTH_007 handling, which loses the 401-vs-429-vs-5xx distinction that connection-test classification needs.

I checked this out locally and ran your new suite plus the existing regression suites you listed:

• tests/unit/zai-web-auth-semantics.test.ts — 4/4 pass
• provider-validation-web-cookie-auth007.test.ts + web-cookie-validation-proxy-7058.test.ts + executor-zai-web.test.ts — 34/34 pass
• Focused ESLint on the touched files — clean

The implementation follows the existing specialty-validator pattern (same shape as chatgpt-web/grok-web/kimi-web), reuses extractZaiToken() through the correct service boundary instead of reaching into the executor tree directly, goes through the SSRF-guarded validationRead() transport, and never consumes the upstream response body — all nicely covered by your tests. Dropping the Cookie header and only sending Authorization: Bearer <token> is also a nice reduction in exposure versus the old generic probe.

One small, non-blocking note for later: tests/unit/web-cookie-validation-proxy-7058.test.ts calls validateWebCookieProvider() directly and still uses zai-web as its example provider hitting /api/models — after this PR, zai-web no longer reaches that path via the normal validateProviderApiKey() dispatcher, so that test's docstring is a little stale (it still correctly exercises the generic function itself, which other providers still use). Not something you need to touch in this PR.

This looks merge-ready to me. Thanks for the thorough root-cause writeup and the live semantic verification notes — makes review a lot faster.

[diegosouzapw]

Validated in local merge-train .claude/worktrees/merge-train-20260816-000002-suite.log on devbox-vm-06-dev002 @ 8be62df65f61cc4cf29cdc3e6bc38173ffafa4e3 (FAST gates green: static + changed tests + vitest; daily full-suite run still required). Merged under the batch merge-train protocol (merge-gates §7). ⚠️ base-red inherited: #10523 (ServiceSupervisor order-dependent test, not touched by this batch).