fix(fetch): 3-stage SSR fallback in extract_content_from_html (#3878)

[ZhangJing-gugugaga]

Problem

Pages that use progressive SSR (Next.js streaming, Remix deferred, custom
Lambda SSR) deliver content in two phases: a small visible loading shell,
then the real content in a hidden container
(visibility:hidden; position:absolute; top:-9999px) that becomes
visible only after client-side hydration.

Mozilla Readability treats those hidden elements as non-content and
strips them, so extract_content_from_html silently returns just the
loading shell (e.g. "Unified Serverless Framework …") with no indication
that content was lost.

Upstream PR #3922 proposes a fix; this PR ports the same design.

Fix

src/fetch/src/mcp_server_fetch/server.py — 3-stage fallback in
extract_content_from_html:

• Stage 1: readabilipy + Readability (existing behaviour, unchanged
  for normal readable pages).
• Stage 2: readabilipy without Readability when Stage 1 produced
  < 1% of the HTML size as text — keeps visibility:hidden markup.
• Stage 3: raw markdownify of the original HTML as a last resort.

Normal readable pages always hit Stage 1 only and are byte-for-byte
unchanged.

Verification

cd src/fetch && uv sync --frozen --all-extras --dev && uv run pytest tests/test_server.py -q

23 passed in 8.20s

The existing TestExtractContentFromHtml suite (3 tests, zero-behaviour-change
contract) still passes. Added TestExtractContentFromHtmlFallback (3 tests):
empty input errors, Stage 2/3 don't crash on an empty Stage 1, long readable
Stage 1 is unaffected.

Notes

• No new runtime dependencies.
• Adds tests/conftest.py to inject src/ onto PYTHONPATH so pytest
  collects mcp_server_fetch. The repo's other Python servers appear to
  configure this same way via [tool.uv] or equivalent; I used a
  conftest.py to stay minimally invasive.

Fixes #3878.