fix(fetch): accept socks proxy alias

[he-yufeng]

Description

Accept socks:// proxy URLs as a SOCKS5 alias in the fetch server.

HTTPX accepts socks5://... but raises Unknown scheme for proxy URL for the common socks://... form. That can happen either when users pass --proxy-url socks://... or when the surrounding client process provides ALL_PROXY=socks://....

This keeps the existing proxy behavior for normal http://, https://, and already-valid SOCKS URLs, but normalizes the invalid alias before creating the HTTPX client.

Fixes #767.

Publishing Your Server

Not applicable; this changes the existing fetch server.

Server Details

• Server: fetch
• Changes to: proxy URL handling and fetch server dependencies/tests

Motivation and Context

Some tools and desktop environments expose local proxy settings as socks://127.0.0.1:.... HTTPX does not accept that scheme directly, so fetch fails before it can request the page. Treating socks:// as socks5:// matches the practical meaning users expect and avoids requiring each MCP client to rewrite the proxy URL first.

The dependency is also changed to httpx[socks] so SOCKS support is installed with the fetch server package.

How Has This Been Tested?

• .\.venv\Scripts\python.exe -m pytest tests\test_server.py::TestFetchUrl::test_fetch_with_proxy tests\test_server.py::TestFetchUrl::test_fetch_accepts_socks_proxy_alias tests\test_server.py::TestFetchUrl::test_fetch_accepts_socks_proxy_from_environment -q -> 3 passed
• .\.venv\Scripts\python.exe -m ruff check src\mcp_server_fetch\server.py tests\test_server.py -> passed
• .\.venv\Scripts\python.exe -m py_compile src\mcp_server_fetch\server.py tests\test_server.py -> passed
• .\.venv\Scripts\python.exe -m build -> passed
• git diff --check -> passed
• Secret scan on touched files -> no matches

I also ran .\.venv\Scripts\python.exe -m pytest tests\test_server.py -q. It reached 21 passed / 1 failed. The failing test is TestExtractContentFromHtml.test_empty_content_returns_error, where the current Windows pure-Python readabilipy fallback returns an empty string for empty HTML. That is unrelated to the proxy path changed here.

Breaking Changes

None.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

The README already documents --proxy-url; this patch does not introduce a new option. It only accepts a proxy URL form that users commonly inherit from their environment.