fix(web): explain reader-side refusals instead of surfacing a bare HTTPError

[Adkr1989]

Problem

On some networks r.jina.ai answers 401 — it declines to serve the caller's egress IP. The request never reaches the target page, but WebChannel.read() let the raw urllib.error.HTTPError escape, so the caller saw only:

HTTP Error 401: Unauthorized

That is indistinguishable from a genuinely missing page, and it points the reader at the wrong suspect (the target site) instead of the reader.

check() cannot help here: it is deliberately the zero-overhead tier-0 fallback and never probes the network, so doctor reports the web channel as available regardless. read() is therefore the only place a caller can find out what actually happened.

Change

• read() reinterprets 401 / 403 / 429 as a RuntimeError naming the cause (reader-side refusal, usually egress-IP rate limiting or a block), noting that doctor still shows the channel as green, and pointing at the alternatives.
• The original HTTPError is chained with raise ... from e, so the status code stays reachable for anything logging the chain.
• Every other status propagates untouched — a real 404 is still a 404.

No behaviour change on the success path, no new dependency, check() still touches no network.

Tests

tests/test_web_channel.py gains two parametrized cases:

• test_read_explains_a_reader_side_refusal — 401/403/429 raise RuntimeError, the message carries the status code, and __cause__ is the original HTTPError.
• test_read_leaves_other_http_errors_untouched — 404/500/502 propagate as HTTPError.

pytest tests/test_web_channel.py -q  →  47 passed
pytest tests/ -q                     →  560 passed, 28 skipped, 4 failed

The 4 failures are pre-existing on main in this environment: they are symlink-creation tests that need SeCreateSymbolicLinkPrivilege on Windows (WinError 1314), and are unrelated to this change.