fix: improve cancellation handling for shell and MCP flows

[sunipan]

Summary

Improve cancellation handling for shell commands and MCP server initialization so Forge can recover more gracefully when a model/tool flow is interrupted mid-run.

Context

This PR was prepared with AI assistance by me after repeatedly hitting a bad cancellation state in ForgeCode.

The failure mode I was seeing locally:

• I cancelled a model mid-flow.
• macOS showed a Python crash dialog.
• ForgeCode got stuck in a state where neither CTRL+C nor CTRL+D would get me out.
• I had to close the terminal and reopen it to use Forge again.

I am using cmux, so that environment may be part of the trigger or may make the failure mode easier to reproduce. However, with these changes, I was still able to get the Python crash dialog, but ForgeCode itself appeared to keep functioning correctly after a mid-flow cancellation.

This PR does not try to fix the upstream Python-side crash directly. Instead, it makes Forge’s process and MCP cleanup paths more resilient when cancellation interrupts an in-flight shell/MCP operation.

Changes

• Add a small RunningCommand wrapper for shell command children so dropped/cancelled commands are cleaned up explicitly.
• On Unix, attempt a graceful SIGINT before escalating to kill after a short grace period.
• Disable Tokio’s immediate hard kill_on_drop behavior for Forge-managed shell commands so cancellation can follow the graceful cleanup path.
• Disable Tokio hard kill_on_drop for stdio MCP child commands so the MCP transport can attempt graceful shutdown.
• Make MCP initialization tolerant of per-server failures/timeouts instead of failing the entire MCP registry.
• Preserve last-known MCP tools during MCP reload until the next initialization completes.
• Track failed MCP servers separately so successful servers remain usable.

Key Implementation Details

Shell command cancellation is now managed by a wrapper that sends SIGINT on Unix and then waits up to 3 seconds before killing the child process if it has not exited.

MCP server loading now runs per-server initialization behind each server’s configured timeout. Failed or timed-out servers are collected into the McpServers failure map, while successful servers are still published.

Reloading MCP clears the persisted cache and invalidates the config hash, but it does not eagerly wipe the in-memory tool registry. That keeps previously working tools available until the next initialization pass completes.

Use Cases

• Cancelling an in-progress model/tool flow should not leave Forge stuck in a terminal state that requires closing and reopening the terminal.
• One slow or broken MCP server should not prevent other configured MCP servers from remaining usable.
• Reloading MCP should not briefly remove every MCP tool from Forge before the next lazy initialization completes.

Testing

Ran the focused tests and checks locally:

cargo test -p forge_infra executor::tests
cargo test -p forge_services mcp::service::tests
cargo check -p forge_infra -p forge_services
cargo clippy -p forge_infra -p forge_services --all-targets -- -D warnings

Results:

• forge_infra executor tests: 13 passed
• forge_services MCP service tests: 9 passed
• cargo check: passed for changed packages
• cargo clippy: passed for changed packages

Notes for Reviewers

This is an AI-assisted PR from a real local failure case. The cancellation trigger may involve my local cmux setup, but the behavior this changes is within Forge’s shell/MCP cleanup path and should improve resilience generally.

[CLAassistant]

All committers have signed the CLA.