bug(cli): cancelling MCP management can leave processes and stale results

### What happened

Cancelling an in-flight MCP management action with `Esc` or `q` dismisses the TUI overlay, but does not reliably cancel the underlying operation.

For slow or hung MCP operations this can leave an stdio child process running after the UI has returned. A completion from the cancelled operation can also arrive later and overwrite newer MCP status, configuration, host capability, publication, or credential state.

Expected behavior: leaving the operation aborts its work, reaps any stdio child process it started, rolls back a late write when safe, and prevents stale completions from publishing state.

### How to reproduce

1. Run Maka from source and configure an MCP server whose stdio startup or management request can be held open (a hanging stdio test server also reproduces this deterministically).
2. Open `/mcp` and start a management action such as test, reconnect, disconnect, or an edit that synchronizes the server.
3. While the operation is still pending, press `Esc` or `q`.
4. Start another MCP action or change the same server/credential state.
5. Observe that the first promise can continue after its overlay closes; for stdio transports its child can remain alive, and its late result can replace the newer state.

The race is also reproducible with deferred MCP transport, configuration, host-profile, and credential-store test doubles, which makes the stale publication deterministic.

### Environment

- Maka commit: `3fdaddb4b` (`main` at reproduction time)
- OS and version: macOS 15.7.3 (arm64)
- Surface: TUI / CLI
- Node.js version: 24.14.0
- npm version: 11.19.0

### Logs, screenshots, or additional context

This affects the MCP management surface introduced under #3838. The failure was reproduced before implementing the fix, including the cancellation, child-process cleanup, and stale-result races described above.

This issue was prepared and submitted by OpenAI Codex on behalf of @liuxiaocs7.