fix(runtime): bump managed codex-acp to 0.15.0

[szafranski]

Description

Bumps ManagedAcpToolId::CodexAcp version in crates/aionui-runtime/src/acp_tool_runtime/types.rs from 0.14.0 to 0.15.0, and updates the version literals in the acp_tool_runtime test fixtures to match.

Why: codex-acp 0.14.0 parses service_tier in the shared ~/.codex/config.toml as a strict enum (fast/flex) and aborts on "default" — the value the official Codex CLI/Desktop itself writes there. The builtin Codex agent then fails to start (USER_AGENT_STARTUP_FAILED). codex-acp 0.15.0 relaxed the field and accepts any value. Full diagnosis with stderr logs: iOfficeAI/AionUi#3225.

Companion to iOfficeAI/AionUi#3279, which bumps the same pin in AionUi's prepare-managed-acp-tools.sh (bundling + CDN publish pipeline).

Notes for maintainers

• The managed ACP artifacts for codex-acp/0.15.0 are not yet published on static.aionui.com/managed/acp (currently 403). The download path needs those artifacts published (same note as in fix(acp): bump bundled codex-acp to 0.15.0 AionUi#3279); the bundled-resources path needs AionUi to bundle 0.15.0.
• No DB migration is needed: since migration 009_builtin_managed_acp_tools.sql the builtin Codex row no longer persists a command/args pin — runtime resolution derives the version from ManagedAcpToolId::version().

Verification

• scripts/check-migration-immutability.sh ✅
• cargo fmt --all -- --check ✅
• cargo clippy --workspace -- -D warnings ✅
• cargo test --workspace ✅ (all green; the 5 updated literals are test fixtures coupled to ManagedAcpToolId::version())

🤖 Generated with Claude Code

[szafranski]

Small coordination bump: this is the AionCore side of the codex-acp 0.15.0 bump, paired with iOfficeAI/AionUi#3279. The UI/bundling pipeline can point at 0.15.0, but the managed runtime resolution also needs this backend version pin so the built-in Codex agent fix is consistent across install paths.

Could we keep this paired with the AionUi companion for the next release/bundle? Thanks!