fix(fetch): fix fetchurl tool incorrect output when fetching via service fails

[stdrc]

…ice fails

Related Issue

Resolve #(issue_number)

Description

[Copilot]

Pull request overview

This PR fixes an issue where the FetchURL tool would return incorrect output when fetching via the Moonshot fetch service fails. The fix improves error handling and implements a proper fallback mechanism to the local HTTP GET method.

Key Changes

• Added try-except block to catch aiohttp.ClientError exceptions when calling the fetch service, providing better error messages
• Refactored ToolResultBuilder initialization to be created within each fetch method rather than in the main __call__ method
• Extracted HTTP GET fetching logic into a separate static method fetch_with_http_get for better code organization

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/kimi_cli/tools/web/fetch.py	Improved error handling for fetch service failures with network error catching, and refactored builder initialization
CHANGELOG.md	Added entry documenting the fix for FetchURL tool output issue

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The ToolResultBuilder() is now created with default parameters, which includes max_line_length=2000. Previously, the builder was created with max_line_length=None to avoid truncating long lines in web content. This change might cause long lines in fetched content to be truncated.

Consider using ToolResultBuilder(max_line_length=None) here to maintain the previous behavior, especially since:

1. Web content (HTML/markdown) often has long lines
2. The SearchWeb tool in the same module uses max_line_length=None for similar reasons
3. Extracted text from trafilatura can contain long lines

Suggested change

	builder = ToolResultBuilder()
	builder = ToolResultBuilder(max_line_length=None)

[Copilot]

The new error handling for network errors when calling the fetch service lacks test coverage. While there's a test for successful service calls (test_fetch_url_with_service in tests/test_fetch_url.py), there's no test for when:

1. The service is unreachable (network error)
2. The service returns a non-200 status code with the new error path

Consider adding tests to verify:

• The fallback to HTTP GET works when the service encounters a network error
• The error message format is correct for network errors
• The logging behavior (warning message at line 36)