[Bugfix #1128] Bump @openai/codex-sdk to ^0.142.5: restore the codex consult lane on macOS (XProtect kill)

[amrmelsayed]

Summary

Bumps @openai/codex-sdk from ^0.130.0 to ^0.142.5 in packages/codev. This restores the consult -m codex lane on macOS 26, where XProtect SIGKILLs the unsigned 0.130.0 vendor binary on first launch, auto-trashes it, and leaves every subsequent invocation failing with a raw spawn ... ENOENT.

Fixes #1128

Root Cause

@openai/codex-sdk 0.130.0 pins @openai/codex 0.130.0 exactly, and that version's darwin vendor binary (~192 MB Mach-O) is not code-signed. macOS 26 XProtect flags it as malware at exec time, kills it, and the default dialog action moves it to Trash, which is why the first failure is SIGKILL and every later one is ENOENT.

Investigation finding that reshaped the fix: @openai/codex 0.142.5 ships the same binary Developer ID-signed (Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2), hardened runtime, full Apple chain). Upstream fixed the root cause between 0.130.0 and 0.142.5. The old caret range could never pick this up on its own: for 0.x versions, ^0.130.0 only spans 0.130.x.

Fix

• packages/codev/package.json: @openai/codex-sdk ^0.130.0 → ^0.142.5
• pnpm-lock.yaml: refreshed; zero remaining references to 0.130.0
• No code changes: SDK 0.142.5's API surface is unchanged for everything runCodexConsultation uses (verified against the published .d.ts, and by clean TypeScript compile + full test suite)

Scope decisions agreed with the architect on #1128:

• (a) ad-hoc codesign fixup: deferred, not shipped. codesign --remove-signature && --sign - over a valid Developer ID signature would downgrade it to an ad-hoc identity. May return later as a conditional fixup if Apple revokes a future hash; architect will re-scope on consult: codex XProtect / Gatekeeper blocks the vendor binary on macOS (SIGKILL then ENOENT after auto-Trash) #1128.
• (c) legible Gatekeeper error message in consult: follow-on PR, tracked on consult: codex XProtect / Gatekeeper blocks the vendor binary on macOS (SIGKILL then ENOENT after auto-Trash) #1128.

No regression test added: this is a pure dependency bump. The failure mode (XProtect trashing an unsigned third-party binary) is environmental and not reachable from unit tests; verification below is the evidence.

Test Plan

All on macOS 26, darwin-arm64, in the builder worktree:

• Reproduced the bug pre-fix: consult -m codex fails with spawn .../codex-darwin-arm64/vendor/aarch64-apple-darwin/codex/codex ENOENT (binary already trashed by XProtect)
• codesign --verify --strict passes on the 0.142.5 vendor binary; authority chain is OpenAI OpCo, LLC (2DC432GLL2) → Developer ID CA → Apple Root CA, hardened runtime flag set
• spctl --assess --type execute returns "rejected (the code is valid but does not seem to be an app)": identical output to the known-good standalone codex CLI used daily on this machine; this is spctl's standard response for any signed non-app-bundle CLI, not a Gatekeeper failure
• Binary launches cleanly (codex-cli 0.142.5, exit 0) with no SIGKILL and no XProtect dialog, and survives on disk after exec (the old failure mode deleted it at this point)
• End-to-end user path: node ./bin/consult.js -m codex --prompt "Reply with the single word: ping" from the worktree build round-trips in 7s, exit 0
• pnpm build (root, core first) clean; full pnpm test in packages/codev: 3432 passed, 0 failed
• porch phase checks (build + tests) green