fix: improve macOS restart and mixed Responses relay handling

[ASH521]

Summary

This PR fixes two issues that are still reproducible on the current upstream main:

1. macOS restart from the manager does not reliably close and relaunch the Codex app.
2. Mixed relay mode for the Responses API can fail on relays that do not support hosted image-generation tools, and the failure is surfaced through the local protocol proxy as a misleading Chat Completions proxy error.

The two fixes are related from a user workflow perspective: both affect the manager's ability to apply a working Codex/Codex++ runtime after switching between official API and relay configurations. I am happy to split this into two PRs if that is easier to review.

Problem 1: macOS restart reliability

Symptom

On macOS, clicking restart from the manager can leave the current Codex/Codex++ process running instead of closing it and starting a fresh instance. Manually quitting the app first, then launching again, works.

Cause

The restart path only stopped broad launcher/Codex process names. It did not consistently:

• Resolve the actual target .app bundle before cleanup.
• Stop Codex-related processes associated with that bundle.
• Clear processes that still own the debug/helper/launcher-guard ports.
• Wait for those ports to become available before spawning the silent launcher.

That can make the relaunch race the previous app instance or fail because a required port is still busy.

Fix

This PR adds a macOS launch-preparation step used by both launch and restart:

• Resolve the selected/saved Codex app path before launching.
• Stop launcher processes.
• Stop Codex processes for the resolved app bundle.
• Stop only Codex-related processes listening on the debug port, helper port, or launcher guard port.
• Wait briefly for those ports to clear before starting the silent launcher.
• Add diagnostic events for cleanup requested/completed states.

The port cleanup is intentionally constrained to Codex-related processes to avoid killing unrelated local services.

Problem 2: mixed Responses relay with hosted image tools

Symptom

In mixed relay mode, a request to the local Responses endpoint can fail with a 502 like:

unexpected status 502 Bad Gateway: {"status":"failed","message":"Chat Completions protocol proxy is not enabled"}, url: http://127.0.0.1:57321/v1/responses

A relay may support /v1/responses text traffic but reject hosted image-generation tools. In that case the current request path can leave the user with a misleading local proxy error instead of a working text request.

Cause

The protocol proxy was enabled only for Chat Completions relay mode. Mixed relay mode can also need the local proxy when the active protocol is Responses and the relay is using the official API-key mix.

In addition, the payload still carried hosted image-generation tool declarations and related response includes/tool choices. Some third-party Responses-compatible relays reject those fields even when the user is not trying to generate an image.

Fix

This PR updates the mixed Responses relay handling to:

• Enable the local protocol proxy for Responses relay profiles that use the official API-key mix.
• Route local /v1/responses requests through the proxy in that mixed case.
• Strip hosted image-generation tool declarations before forwarding to the relay:
  • image_generation
  • imageGeneration
  • image-generation entries inside allowed tool lists
  • forced image-generation tool_choice
  • include entries such as image_generation_call.*
• Keep the Chat Completions conversion path available for Chat Completions relay mode.
• Add focused tests for the sanitizer, protocol routing, and relay config generation.

This keeps text Responses traffic usable on relays that do not support hosted image generation, while avoiding an accidental fallback into an unsupported Chat Completions path.

Validation

Ran the focused Rust test set locally:

cargo test -p codex-plus-core --test launcher --test watcher --test protocol_proxy --test relay_config

Result:

• launcher: 39 passed
• watcher: 8 passed
• protocol_proxy: 17 passed
• relay_config: 21 passed

Notes

The PR also includes short hotfix notes documenting the investigation and behavior changes for each issue.