fix(proxies): order pool candidates by crossed short-memory health signals

[maxmad64bis]

⚠️ base-red inherited: #13866

Summary

A pool member that just failed keeps getting served first until it is set aside. Candidates are now ordered by crossed short-memory health signals (refusal memory plus last cached probe verdict), so a request lands on the first useful try instead of paying the failed head first. Opt-in behind PROXY_SKIP_RECENTLY_FAILED (off by default); ordering only, nobody is removed and no status is mutated.

Related Issues

• Related to feat(proxies): stop re-serving a proxy that just failed #13578
• Related to feat(proxies): stop re-serving a pool member the provider just refused #13602

Validation

• Change type: provider
• Focused tests and category gates from the golden path
• npm run lint — targeted ESLint clean; full run is red on the base (same TS2677 pair, inherited, see Reviewer Notes)
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

Tests Added Or Updated

• tests/unit/proxy-pool-rank-candidates.test.ts (new, 8 cases: avoided-last, no-signal order, all-set-aside order, negative probe, first-useful-try, held sticky, canonical probe URL, flag-off identity)
• tests/unit/proxy-pool-skips-refused-member.test.ts (updated: final assertion reflects cursor advancing past the served member on the ranked list)

Coverage Notes

• src/lib/db/proxies/rotation.ts covered by the 8 new cases plus the updated neighbor; neighbors proxy-pool-rotation-6365 (8/8), proxy-rotation-latency (4/4), proxy-pool-chat-path-rotation-13575 + pool-ip-quota-429-path (8/8) stay green.

Reviewer Notes

• Sticky with a live window bypasses the rank entirely and keeps its held member; the existing eligible-skip still replaces a set-aside held member for one pick without writes. Expired sticky, round-robin, random, and latency rank normally. A fully set-aside pool keeps its input order (fail-closed, unchanged).
• Only in-memory signals are read (refusal memory, cached probe verdict); 401/403 never order against an address and no database read happens per request. Local gates pass: file-size OK, complexity under baseline, targeted ESLint and typecheck:core clean, new tests 8/8, neighbors green.
• CI reds are inherited from the red base (🔴 Release branch not green: release/v3.8.51 #13866), not from this diff: the third-party PR fix(sse): treat antigravity empty completions with a normal stop as valid 200s (#14160) #14243 on the same base release/v3.8.51 fails the same 9 jobs (API Route Typecheck, Docs Gates, Fast Quality Gates, Merge integrity, ESLint, Unit fast-path 1-4/4); every file cited by the failing gates is outside this diff. Non-blocking for this PR.

[diegosouzapw]

Thanks @maxmad64bis — merging via the release merge-train. Validated in local merge-train (mt-train10c) on the devbox @ train tip 4d841aa1c740bbaa03868dc0a403c62099a99a42 with the 72 sibling PRs of this batch: typecheck:core, file-size, complexity, cognitive-complexity, changelog-integrity green; changed-area node:test 831/831 (0 failing) and vitest 480/482 — the two reds are autoCombo/provider-family-combos.test.ts timing out at 20s, which reproduces on the PURE release tip under the full vitest suite (and is already tracked by the Release-Green issue #13866), so it is inherited, not this batch's. Merged --admin per merge-gates §3/§4/§7.