Stabilize OpenSpace MCP daemon lifecycle

[CCLCK]

Summary

This PR stabilizes OpenSpace MCP daemon lifecycle management and adds regression coverage for the process accumulation issues we saw during repeated Codex/OpenSpace session startup.

Key changes:

• move MCP stderr/file logging onto safer paths so MCP transports do not get polluted by stdout noise
• keep remote proxy calls isolated per tool invocation while reusing the daemon process itself
• track daemon last_used_at and active_requests, add cross-key fleet reaping, and install graceful idle/signal shutdown for both main and evolution daemons
• add real-session scenario coverage plus a local cleanup utility for OpenSpace daemon state/processes

Why this prevents the old issue from recurring

Previously, daemon reuse was exact-key only and cleanup was mostly per-key/stale-record replacement. Under repeated reconnects or workspace/config churn, that allowed many detached daemons to sit idle until their individual watchdogs expired.

This change adds runtime-side safeguards instead of relying on manual cleanup:

• daemon metadata now records last_used_at and active_requests
• idle reaping only applies to fully idle daemons
• per-kind daemon fleets are capped via OPENSPACE_MCP_MAX_DAEMONS_PER_KIND
• both MCP server entrypoints now run cleanup on idle shutdown and SIGTERM/SIGINT

Verification

Automated:

• python3 -m pytest -q tests/test_shared_mcp_runtime_metadata.py tests/test_mcp_proxy_runtime.py tests/test_mcp_entrypoints.py tests/test_mcp_stdio.py tests/test_logging_stdout_safety.py tests/test_codex_session_scenarios.py
• Result: 26 passed

Runtime/manual:

• post-restart config preflight against ~/.codex/config.toml reported both openspace and openspace_evolution as ready
• real wrapper-backed search_skills call succeeded after restart/config wiring
• daemon state for newly spawned daemons now writes last_used_at and active_requests

Notes

• A local cleanup_openspace_daemons.py utility is included as operator tooling, but the main recurrence prevention is in the runtime lifecycle path, not the script.