fix: tell the truth about run_tests being blocking

`tool_run_tests` in `server/src/http/mcp/shell_tools/script.rs` is fully
blocking server-side: it spawns the test child, polls every 1s server-side
until exit (or `TEST_TIMEOUT_SECS = 1200s`), and returns the full
{passed, exit_code, output} directly. There is NO async/started-status
return path.

But two places told agents the wrong story:
1. `tools_list/system_tools.rs` description claimed "Returns immediately
   with status: started. Poll get_test_result..." — agents read tool
   descriptions for protocol semantics, so they followed this and burned
   turns polling get_test_result.
2. `agents.toml` had been correctly saying it blocks, but my last commit
   (776aad38) "fixed" it the wrong way based on a misread of the code.

Now both say: run_tests blocks server-side, returns the full result, do
not poll get_test_result. get_test_result remains for external observers
(UI checking on a job another caller started).

Reverts the prompt change in 776aad38 with the correct text.

server/src/http/mcp/tools_list/system_tools.rs

@@ -97,7 +97,7 @@ pub(super) fn system_tools() -> Vec<Value> {
         }),
         json!({
             "name": "run_tests",
-            "description": "Start the project's test suite (script/test) as a background job. Returns immediately with {\"status\": \"started\"}. Poll get_test_result with the same worktree_path to check for completion. If the previous run already finished, returns the result inline.",
+            "description": "Run the project's test suite (script/test). Blocks server-side until tests finish (up to 20 minutes) and returns the full result {passed, exit_code, timed_out, tests_passed, tests_failed, output}. No polling needed; do NOT call get_test_result for the same job — that tool exists only for external observers.",
             "inputSchema": {
                 "type": "object",
                 "properties": {