fix(toolbox-core): treat MCP CallToolResult.isError as an error (not a plain string)

### Summary
When the Toolbox server returns a successful MCP `tools/call` response whose result has `isError: true`, the Python SDK currently flattens the `content` into a normal string result. This means callers cannot reliably distinguish success vs failure, and ADK callbacks cannot handle these failures as structured error output.

PR #596 (fix(adk): wrap tool execution errors into error output) only wraps **Python-side exceptions** raised during execution/validation. Server-side tool failures represented via MCP `CallToolResult.isError=true` do **not** raise exceptions today, so they bypass the ADK wrapper.

### Affected Area
- `packages/toolbox-core` MCP transport result processing
- `packages/toolbox-core/src/toolbox_core/mcp_transport/transport_base.py` (`_process_tool_result_content`)
- versioned MCP clients that call it, e.g. `packages/toolbox-core/src/toolbox_core/mcp_transport/v20251125/mcp.py`

### Repro (high level)
1. Run a Toolbox server with a tool that returns an MCP tool result with `isError: true` (common when the server reports a tool execution failure).
2. Invoke the tool via `toolbox-core` (and/or via `toolbox-adk`).

### Actual
- SDK returns a normal string like `"error processing request: ..."`.
- No exception is raised, so wrappers like `toolbox-adk` cannot convert it into `{ "is_error": true, ... }`.

### Expected
One of the following (project preference):
- Raise a typed exception in `toolbox-core` when MCP tool result `isError=true`, OR
- Return a structured error object (or otherwise expose an error signal) instead of a plain string.

### Why this matters
Downstream frameworks (ADK, LangChain, LlamaIndex) need a consistent way to detect tool failures and run after-tool callbacks / recovery logic. Right now only *exception-based* failures are catchable.

### Related
- PR: https://github.com/googleapis/mcp-toolbox-sdk-python/pull/596