[maxmad64bis]

Summary

• The sweep and the "Test All" endpoint only ever probe the generic PR feat(backend): rate-limit-resilient, configurable proxy health-check probe target #8411 target
  (httpbin.org/ip by default). fix(antigravity): classify geo-blocked egress, exclude account, real connection probe #10420 established the same principle for per-connection
  "Test Connection" checks: a generic probe can stay green while the real model surface fails.
  This generalizes that to proxy health.
• src/lib/proxyHealth/providerProbeTarget.ts resolves, for a given proxy, the real host of the
  provider it is assigned to (getProxyWhereUsed), then probes GET {baseUrl}/models through
  the existing url helpers (getRegistryEntry + addModelsSuffix) — no new URL construction.
• Eligibility is deliberately narrow: only providers with a registry entry carrying a singular
  baseUrl (or testKeyBaseUrl) qualify. antigravity/agy only has baseUrls[] (a custom
  urlBuilder), so it is excluded by construction, without any special-casing — its
  "Test Connection" flow probes by a real generation call, and this change never bills one.
  Self-hosted / custom-baseUrl providers are excluded too: their real target lives in a
  connection's providerSpecificData, not the provider itself, and a proxy is assigned to a
  provider, never to one specific connection.
• A resolved target can still be one nobody can reach — some registry baseUrls are placeholders
  (databricks's default is a 16-zero azuredatabricks.net host). testOneProxy and
  testSingleProxy already treat a 5xx from the target as inconclusive rather than a proxy
  fault; a connection-level failure against a provider-resolved target now gets the same
  treatment — only the operator-configured generic target is trusted enough for "can't connect"
  to mean "proxy is at fault". Target resolution itself falls back to the generic target on any
  error, so a DB hiccup can never make a proxy silently drop out of a sweep's results.
• The generic target's HEAD works for httpbin.org/ip but not necessarily for a real
  provider's /models endpoint (many reject HEAD). The probe method is GET for a
  provider-resolved target and stays HEAD for the generic one — the generic path is otherwise
  untouched.

Related Issues

• Closes part of feat(backend): rate-limit-resilient, configurable proxy health-check probe target #8411 (provider-aware target; the unification half is fix(api): share one probe-target resolution between both proxy health checks #10657, the
  blocked-outcome half is fix(api): a target refusing the egress IP is not a healthy proxy #10654)

Validation

• Change type: routing / proxy health (+ env docs)
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

$ node --import tsx/esm --test tests/unit/provider-probe-target.test.ts
# tests 16   # pass 16   # fail 0

# 5 pre-existing proxy-health-* suites: 22/22 pass, unaffected

$ npm run lint            # rc=0
$ npm run check:cycles    # OK — no cycles
$ npm run check:docs-all  # rc=0
$ npm run typecheck:core  # rc=0

⚠️ base-red inherited: #9985

Tests Added Or Updated

• tests/unit/provider-probe-target.test.ts (new, 16 tests):
  • isProbeSafeBaseUrl tested directly (https-only, query-string rejection, non-http(s)
    schemes, empty input) — no registry entry needed, so this guard's own correctness doesn't
    depend on the registry never drifting.
  • resolveEligibleProviderUrl checked against two real registry entries: groq (eligible,
    plain baseUrl) and antigravity (ineligible — baseUrls[] only, no singular baseUrl).
  • resolveProviderProbeTarget checked against a real database (assignProxyToScope): no
    assignment, provider assignment, ineligible-provider assignment, the kill switch off, a
    global-scope assignment (must not be mistaken for a provider one), and multiple assignments
    (first eligible one wins).

Coverage Notes

• src/lib/proxyHealth/providerProbeTarget.ts is new and fully covered by the 16 tests above.
• scheduler.ts and auto-test/route.ts each gain a few lines of wiring (target/method
  selection); covered indirectly through the existing proxy-health-* suites, which still pass
  unchanged.

Reviewer Notes

• PROXY_HEALTH_USE_PROVIDER_TARGET (default enabled) restores the prior behavior when set to
  "false". Default-on is deliberate: with the inconclusive-on-connection-failure safeguard
  above, a proxy is never penalized for a provider's target being unreachable, so there is
  nothing left for an opt-in default to protect against — happy to flip it if you'd rather ship
  this opt-in regardless.
• Only the registry-backed proxy_assignments table is read. The legacy per-provider proxy
  config (/api/settings/proxy?level=provider&id=...) has no proxy→provider reverse lookup;
  building one would be new machinery rather than reuse. A legacy-only assignment degrades
  safely to the generic target, same as no assignment at all.
• Not every eligible provider's /models measures much (some web-cookie hosts return 401/404
  for an unauthenticated GET) — that's fine for a reachability check, since the proxy is still
  correctly classified as "ok" (it relayed), just not a signal that the provider account itself
  is healthy. That's out of scope here; account/credential health is a separate, existing
  mechanism.