fix(proxy-logs): keep the HTTP status the provider actually returned on search rows

[maxmad64bis]

⚠️ base-red inherited: #13866

Summary

Search proxy-log rows always read "no response received", even when the provider answered with a 429, 403, or 500. The chat writer already captures the received status; the search writer never forwarded it. After this change, search rows carry the status the provider actually returned, and keep null only when no response arrived.

Related Issues

• Related to feat(proxy-logs): keep the HTTP status the provider actually returned #13580 (the chat writer this extends to search).

Validation

• Change type: provider
• Focused tests and category gates from the golden path
• npm run lint — ESLint 0 on the two touched source/test files; the full eslint . run is red on the base, unrelated to this diff.
• Reconciled with the current active release base; focused checks rerun afterward — rev-list --count HEAD..upstream/release/v3.8.51 = 0, gates re-run after the last amend.
• Production-code changes include a new or updated automated test in this PR — new tests/unit/search-proxy-upstream-status.test.ts (6 cases, RED-then-GREEN).

Tests Added Or Updated

• New tests/unit/search-proxy-upstream-status.test.ts (6 cases, local HTTP server, journal capture): real 429/200/500 arrive on the row (RED before: null), transport timeout and synthesized envelope codes stay null; neighbor search-432-plan-limit-cooldown.test.ts still green (7/7).

Coverage Notes

• Single-file change plus test: executeProviderFetch is the only search path, so every search provider is covered without a list.

Reviewer Notes

• Never copies a locally fabricated code into upstream_status (envelope 402/502, transport 502/504, and post-hoc derived statuses stay null). Local gates: targeted ESLint 0, typecheck:core 0, new test 6/6 RED-then-GREEN, C4 re-run at push time (P2 merged, migration 179 present on the base).

• CI: red jobs are inherited from the red base (🔴 Release branch not green: release/v3.8.51 #13866), not from this diff — the third-party fix: accept ChatGPT cookie headers for clean-room sessions #14219 at the same base fails the same gates (api-typecheck 2 ✖ plus quality/docs/eslint/unit fast-path reds); all three files of this diff are outside the cited files. Non-blocking for this PR.

• 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.