fix(combo): network errors must not trip provider circuit breaker

[HouMinXi]

Re-cut of #9125 onto the live release/v3.8.50 tip. The original branch's
merge-base sat 20 commits back, and its file-size-baseline.json commit
re-encoded every non-ASCII character in that file as \uXXXX, so the baseline
alone read as +186/-185. Same fix, minus the noise: 8 files, +146/-27, and
the baseline touch is now +4/-3.

This reverses the direction #8376 took

That is the part worth your attention, so stating it up front rather than
burying it in the diff.

#8376's position. isProxyUnreachable was added as an override that forces
the breaker to trip even when the next combo target is on the same provider.
The reasoning, quoted from the code it replaced: a dead upstream proxy poisons
every account on that provider identically, so a homogeneous same-provider
combo pool would never trip the breaker and would instead burn every attempt
against the same dead proxy until it hit the 503 max-retry limit.

This PR's position. ECONNREFUSED and ETIMEDOUT are transport failures --
the request never reached the provider, so the provider may be perfectly
healthy and only the local network path is broken. Tripping the provider
breaker blocks every account for 30-60s on state that outlives the request.
With an intermittent VPN that compounds into cascading ALL_ACCOUNTS_INACTIVE
503s. CLAUDE.md defines the provider breaker as the response to "a provider
that is repeatedly failing at the upstream/service level"; a dead local proxy
is not that, so #8376 arguably filed the symptom under the wrong mechanism.

What replaces #8376's mitigation. The retry-burning it worried about falls
to per-model lockout, which handleComboChat already records on the first
transient failure for any status in the model-lockout error set (502 included
by default). That is a narrower blast radius than a whole-provider trip.

If you prefer #8376's tradeoff, this PR is the one to reject -- the two
positions cannot both hold.

Also in scope

Rate-limit queue timeouts get the same treatment. RATE_LIMIT_QUEUE_TIMEOUT
and RATE_LIMIT_QUEUE_WEDGED are OmniRoute's own backpressure, not a provider
failure, and they were reaching the breaker through the 503 status gate.

A test-quality note

Five of the existing 8376-econnrefused-breaker.test.ts cases passed
sameProviderNext: true. With that set, !args.sameProviderNext is already
false, so shouldRecordProviderBreakerFailure returns false no matter what the
case was nominally testing -- each of those five asserted false and would
have passed with its named guard deleted. They now pass sameProviderNext: false so the guard under test is the one that actually decides the result.

Testing

node --import tsx/esm --test tests/unit/breaker-network-error-guard.test.ts tests/unit/8376-econnrefused-breaker.test.ts -- 14/14 pass.
npm run typecheck:core clean. check-docs-sync, check:any-budget:t11 and
check:tracked-artifacts all pass.

npm run check:file-size reports one violation on this branch
(open-sse/executors/base.ts 1623 > 1578) and npx eslint reports one
(@/lib/localDb restricted import in chat.ts). Both reproduce on an
untouched release/v3.8.50 checkout, so neither is introduced here, and
neither is fixed here. open-sse/services/accountFallback.ts likewise fails
prettier --check on the untouched tip, at a line this PR does not go near;
left as-is so the diff stays minimal.