Fix macOS entrypoint repair wrappers

[twodogegg]

Summary

Fix macOS entrypoint repair so it does not overwrite installed .app executables with broken shell wrappers.

Why

I reproduced this on macOS with the v1.1.1 DMG. After using the manager repair entrypoint action:

• /Applications/Codex++.app/Contents/MacOS/CodexPlusPlus was replaced by a shell script that executes itself, so launching Codex++ from Alfred/Finder reports that the app is not responding.
• /Applications/Codex++ 管理工具.app/Contents/MacOS/CodexPlusPlusManager was replaced by a wrapper pointing to codex-plus-plus-manager, but that lowercase binary does not exist inside the app bundle.
• The repaired plist referenced codex-plus-plus.png, while the DMG app bundle ships codex-plus-plus.icns, causing launcher/search UIs to show a missing icon.

Changes

• Track both the app bundle executable path and the source target path in the macOS install plan.
• Avoid writing a wrapper when the target is already the installed app bundle executable.
• Fail clearly if an installed app executable is missing and no source binary is available instead of creating a recursive wrapper.
• Resolve the manager app binary path from .app bundles using CodexPlusPlusManager, matching the packaged filename.
• Use the shipped codex-plus-plus.icns in repaired app bundles.
• Add regression tests for self-wrapping and lowercase manager wrapper paths.

Testing

• cargo fmt --check
• cargo test -p codex-plus-core --test installers

Note: cargo test -p codex-plus-core still has an unrelated existing failure on macOS in wrapper_dir_uses_roaming_codex_plus_plus because it expects Windows backslashes in a Windows-style path constructed on macOS.

[BigPizzaV3]

啥问题 简单说一下

[twodogegg]

啥问题 简单说一下
mac os ，第一次运行 codex ++ 的时候可以打开 codex 桌面端，后来过不久打开再打开以后 codex ++ ，显示的图标是一个占位的空图标。然后就启动不了 codex ++了。 我就让codex cli修复了这个问题。