fix(auto-combo): surface strict zero-cost exclusion diagnosis in pool log

[maxmad64bis]

⚠️ base-red inherited: #14547

Summary

When the operator turns on strict zero-cost routing, candidates excluded for lack of a documented hard stop disappear from the pool with only a count in the server log. This change surfaces that exclusion diagnosis (excluded / no-hard-stop share) through the same { pool, diagnosis } shape the paid-only filter already returns, so tooling can report why a pool shrank. Routing is unchanged: the same candidates are kept or dropped, and the log line keeps its exact text.

Related Issues

No linked issue — diagnostic surfacing for an opt-in routing guard with no prior report.

Validation

• Change type: routing
• Focused tests and category gates from the golden path
• npm run lint — ESLint on the touched files is clean; the full run is red on the base (🔴 Release branch not green: release/v3.8.51 #14547)
• 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/autoCombo/strict-zero-cost-diagnosis.test.ts (new, 4 cases: diagnosis values, identity when disabled, identity when nothing excluded, deep-equal content when excluded).

Coverage Notes

• Touched open-sse/services/autoCombo/strictZeroCostFilter.ts (new WithDiagnosis variant plus delegating wrapper) and open-sse/services/autoCombo/virtualFactory.ts (callsite hunk only): covered by the new test plus the existing strict-zero-cost-filter, strict-zero-cost-connection-safety, and paid-model-filter-6512 suites (37 tests green together). No coverage movement expected outside the new branch.

Reviewer Notes

• Log text is byte-identical: only the source of the two numbers changed (strict.diagnosis?.excluded / strict.diagnosis?.noHardStop), the format string is untouched. Verified pre-existing reds only: typecheck:core reports one error in an untouched file (cliproxyAccountHealth.ts:157, identical on the bare base) and check:env-doc-sync fails identically on the bare base.
• API Route Typecheck fails on 4 lines outside this diff (auggie.ts, projectCombo.ts, empty git diff $mb on both). The same 4 lines fail on tierce fix(proxies): rank pool members sharing a refused egress address last #14657 at the same base, so inherited and non-blocking (§12 voie courte, base-red 🔴 Release branch not green: release/v3.8.51 #14547).

Maintainer rework (merge-batch 2026-09-24)

• Merged release/v3.8.51 into the branch (real merge, your commit kept). The release tip had since added a traceInvocationId parameter to filterStrictZeroCostCandidates (per-candidate exclusion tracing via recordAutoExclusion), which conflicted in strictZeroCostFilter.ts and virtualFactory.ts. Resolved by threading traceInvocationId through filterStrictZeroCostCandidatesWithDiagnosis, having the legacy wrapper forward it, and passing it from virtualFactory.ts, so both the tracing and the diagnosis survive. The long warnPoolDrop line was Prettier-reflowed; virtualFactory.ts stays under its frozen ceiling.
• Red→green verified (vitest, tests/unit/autoCombo/strict-zero-cost-diagnosis.test.ts): with open-sse/services/autoCombo/ reverted to the release tip, 4/4 fail; with this PR 4/4 pass.
• Gates on the merged tree: typecheck:core clean, check:open-sse-typecheck 0 errors, eslint clean, check-file-size OK.
• Heads-up: fix(sse): expose exhausted vs unknown counts in strict zero-cost tally #14707 touches the same warnPoolDrop("STRICT", ...) call site (it adds the exhausted/state-unknown split through a describeStrictExclusions() helper), so whichever lands second needs a small conflict resolution there.

[diegosouzapw]

Nice diagnosis-carrying refactor — keeping filterStrictZeroCostCandidates as a thin
wrapper preserves every other caller's contract while giving virtualFactory.ts the
counts in the same pass. I checked this against your other PR #14707 (same file,
same neighborhood) and they merge cleanly in either order — the diagnosis object's
spread of countStrictExclusions()'s return picks up #14707's new
exhausted/stateUnknown fields automatically once both land. Good to merge.