fix: avoid nested tokio runtime panic in --reuse flag

[hossihub]

Problem

The --reuse flag in mcp-http panics with a tokio async runtime error:

cannot start a runtime from within a runtime

This happens because try_acquire_port_lock creates a new tokio::runtime::Builder::new_current_thread() while already running inside the main tokio runtime (the serve_http async function).

Fix

Replaced the manual runtime creation with crate::runtime::run_blocking(), which safely handles both contexts:

• Uses block_in_place when already inside a tokio runtime
• Falls back to the static OnceLock runtime when not

This is the same pattern already used throughout the codebase (orchestrator cache, graph query, web handlers, etc.).

Verification

• cargo build --release — clean
• cargo clippy — no warnings on src/mcp/server.rs
• Manual test: mcp-http --reuse detects existing server and exits cleanly (code 0), no panic