[Bug] execute_task killed at ~60s by MCP client timeout — OpenSpace server is alive and working

Bug Description

When calling mcp__openspace__execute_task via MCP, the call is killed at approximately 60 seconds by the MCP client's tool-call timeout, even though OpenSpace's execute_task typically needs 3-5 minutes (per the project's own docs at ~/.openclaw/workspace-yingbot/AGENTS.md).

The OpenSpace server is actually alive and processing the task during the kill — the cancellation is on the MCP client side, not the server side.

Reproduction Steps

1. Start OpenSpace MCP server (e.g., mcporter start openspace or launchd daemon on 127.0.0.1:8083)
2. From a host agent (e.g., OpenClaw / mcporter client), call mcp__openspace__execute_task with a non-trivial task (e.g., "generate an SVG chart" or "research X")
3. Wait — observe the MCP tool call returns MCP error -32001: Request timed out at ~60s
4. Meanwhile, check OpenSpace server logs (~/OpenSpace/logs/openspace/) — observe that the server is actively processing (e.g., "Step 1/5 → Step 2/5") until the moment of cancellation
5. Result: Task is abandoned mid-execution; output never produced via OpenSpace

✅ Expected Behavior

• execute_task should run to completion (3-5 min typical, scales with max_iterations × tool time)
• The MCP client should respect the documented toolTimeout ≥ 600s requirement (already mentioned in docs)
• If the server takes longer, the MCP client should poll/wait, not kill

❌ Actual Behavior

• MCP error -32001: Request timed out at ~60 seconds
• Server logs show the task was still in Step 1-2 of 5 when killed
• Caller has no way to receive the result

Environment

• OpenSpace repo: https://github.com/HKUDS/OpenSpace (latest main, commit 228f8f7 "fix: Windows PID check")
• Host agent: OpenClaw + mcporter MCP client
• MCP transport: HTTP at http://127.0.0.1:8083/mcp
• Server health: ✅ healthy (returns HTTP 406 with proper JSON-RPC, indicating MCP-protocol is alive)
• Other OpenSpace MCP tools: ✅ working fine (search_skills, fix_skill, upload_skill all respond quickly)
• Affects both max_iterations=10 and max_iterations=20 (both timeout at ~60s)

Suggested Fix

Either (any one of these would unblock the use case):

1. Document the MCP client timeout requirement clearly in README / docs/AGENTS.md, with example configs for mcporter / OpenClaw (e.g., toolTimeout: 600000 for execute_task)

2. Make execute_task a long-running async tool — return a task ID immediately, and add mcp__openspace__poll_task and mcp__openspace__get_task_result to retrieve the result. This is the cleanest fix and works for any MCP client.

3. Add a streaming variant — mcp__openspace__execute_task_stream that emits progress events over the lifetime of the task. This is more complex but gives real-time visibility.

Workaround Currently in Use

Setting the MCP client's tool-call timeout to ≥ 600 seconds (the value already mentioned in OpenSpace's own documentation) on the consumer side. This is fragile and easy to miss for new users — most default MCP client timeouts are 30-60s.

Evidence

OpenSpace server log excerpt (during a killed execute_task call for a "generate SVG" task):

[2026-06-12 16:39:23] [ShellAgent] Step 1/5: Processing task
[2026-06-12 16:39:26] Executing bash script locally
[2026-06-12 16:39:26] [ShellAgent] Step 2/5: Processing task
[2026-06-12 16:39:52] Task execution cancelled  ← MCP client 60s timeout fired here

Net effect: every execute_task call from OpenClaw (and likely any other MCP client with default 30-60s timeouts) silently fails. The fallback behavior is to detect the timeout and run locally, which loses all of OpenSpace's auto-skill-selection, auto-evolve, and grounding benefits.

Thanks for the great project — happy to help test a fix!