feat: support launching multiple Codex++ instances

[zengxiaolou]

Summary

This PR adds first-class support for opening additional Codex++ managed Codex windows from an existing injected Codex++ session.

The current launcher uses fixed debug/helper/guard ports and the default Codex user data directory, so opening another Codex window usually activates the existing instance instead of creating an independent Codex++ connected session. This change gives follow-up instances their own port group and --user-data-dir, while keeping the original default launch behavior unchanged.

Changes

• Add per-launch guard_port and codex_extra_args support to LaunchOptions and the launcher CLI.
• Use open -n on macOS when a --user-data-dir argument is present so a separate Codex app instance is created.
• Add a bridge route, /launcher/new-instance, that spawns the current Codex++ launcher with the next available port group.
• Allocate stable Codex++ instance groups:
  • ctx2: debug 9230, guard 57322, helper 57323
  • ctx3: debug 9231, guard 57324, helper 57325
  • and so on, skipping groups whose ports are already occupied.
• Store additional Codex instance profiles under ~/.codex-plusplus/profiles/ctxN.
• Add a Codex++ menu action and Command+Shift+N shortcut to launch a new Codex++ window.
• Expose guard port and per-launch Codex args in the manager launch form for manual testing/debugging.

Testing

cargo +1.88.0 test -p codex-plus-launcher
cargo +1.88.0 test -p codex-plus-core --test cdp_bridge --test bridge_routes --test launcher
npm run check

Notes:

• cargo fmt --check currently reports unrelated formatting changes in existing files outside this PR. To keep this PR focused, I formatted only the Rust files touched by this change using rustfmt +1.88.0 --edition 2024.
• Tests pass on macOS arm64. Existing warnings remain in codex-plus-core for unused Windows install/proxy helpers.