docs(tests): correct the e2e expected-failure helper guidance

tests/AGENTS.md told tests expecting a tool failure to use
safe_call_tool() directly. The harness disagrees: MCPAssertions
.call_tool_failure() is used at 61 call sites across 13 e2e files and
does strictly more -- it catches the ToolError, asserts the call
actually failed rather than silently succeeding, and matches
expected_error against the extracted message.

safe_call_tool() swallows ToolError and returns a parsed dict, so using
it for an expected failure leaves nothing verifying the call failed. Its
real roles are finally-block cleanup and availability probing, which the
entry now says.

CodeRabbit cites the old line as a coding-guidelines violation whenever
call_tool_failure appears, most recently on #2246.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015c4gkE9mcKu4RiuQzR5eff

Author: kingpanther13

tests/AGENTS.md

@@ -49,8 +49,14 @@ rather than assume the e2e's always-present case.
 ## Test Patterns
 
 - Tests expecting tool **success**: use `mcp.call_tool_success()` inside `MCPAssertions` context
-- Tests expecting tool **failure**: use `safe_call_tool()` directly (catches `ToolError`, returns parsed dict)
-- Service availability checks should use `safe_call_tool` to probe, not `call_tool_success`
+- Tests expecting tool **failure**: use `mcp.call_tool_failure()` inside `MCPAssertions` context.
+  It catches the `ToolError`, asserts the call actually failed rather than silently
+  succeeding, and — when `expected_error` is given — matches it against the extracted
+  error message.
+- `safe_call_tool()` is for calls whose outcome the test does **not** assert: `finally`
+  cleanup (so a cleanup failure cannot mask the real assertion) and service-availability
+  probes. It swallows `ToolError` and returns a parsed dict, so using it for an expected
+  failure means nothing verifies the call failed at all.
 
 ## E2E Test Patterns