Stale '(deleted)' self-exe path can break apply_patch after binary replacement

Summary

apply_patch can fail when the running Codex binary is replaced during an active session, because execution may use a stale self-executable path ending in (deleted).

Why this happens

A tool runtime can receive a previously-captured codex_self_exe path. If the binary is replaced on disk (common in local Codex development), that path may no longer be valid for re-exec.

Repro (Linux)

1. Start Codex from an installed binary path (for example ~/.cargo/bin/codex).
2. Replace/reinstall that binary while the session is still running.
3. Trigger an apply_patch call.

Actual behavior

Sandbox invocation can include a deleted path for the inner command and then fail with ENOENT.
Example shape:
--apply-seccomp-then-exec -- "/home/.../.cargo/bin/codex (deleted)" --codex-run-as-apply-patch ...

Expected behavior

If a captured self-executable path is stale/deleted, runtime should resolve a live executable path and continue.

Current downstream mitigation

Downstream currently mitigates this in apply_patch runtime by rejecting (deleted) self-exe paths and falling back to a live executable resolution path.

Request

Would upstream accept a centralized fix for self-executable resolution (shared utility / single source of truth), so all re-exec callsites are resilient to binary replacement, not only apply_patch?

This seems particularly relevant for developers frequently rebuilding/replacing the Codex binary during active sessions.