fix(ingest): narrow mcp_timeout to our OWN deadline, not the exception type (kø-z follow-up)

Advisor review of the prior commit (5269b7d) found the except TimeoutError
branch was wider than the brief asked for: builtin TimeoutError is also
socket.timeout (3.10+) and asyncio.TimeoutError (3.11+), so any TimeoutError
reaching that clause got relabeled mcp_timeout regardless of source. Gate on
anyio.CancelScope.cancelled_caught instead, mirroring _unwrap_ingest_error's
ownership rule (own it, wrap it; otherwise, untouched).

Measured: no live trigger exists today (MCP's own internal read-timeout
converts to McpError before reaching us; a server-side TimeoutError becomes
an ordinary isError result) -- pinned with a synthetic test raising from
StdioServerParameters construction, inside our fail_after scope but before
either nested task group, so it arrives ungrouped. Four mutations red against
the full 625-test suite: drop the translation, revert to asyncio.wait_for,
relabel the code, and drop the cancelled_caught gate.

Also promotes anyio to a declared direct dependency (was transitive via mcp
only) -- ingest_mcp.py now imports it directly.

pyproject.toml

@@ -18,6 +18,7 @@ dependencies = [
     "pulp>=2.8",                              # deterministisk validator-solver; PuLP bundler CBC i wheelen (R2). Installert 3.3.2.
                                              # PuLP 4.0 vil kreve `pip install pulp[cbc]` + COIN_CMD (Fase-migrasjonsnotat).
     "mcp>=1.28.0",                           # tynn lokal-mappe MCP-server (Step 7) — GA (resolverte 1.28.0) per Step 1-beslutning
+    "anyio>=4.14",                           # kø-(z): ingest_mcp.py bruker anyio.fail_after direkte (MCP-timeout-stien); allerede transitiv via mcp — promotert til deklarert direkte dep (zero new install weight, resolverte 4.14.0)
     "pydantic>=2.11,<3",               # IR/validering (B1) — eksplisitt pin til STABIL 2.x, aldri alpha
     # S3.1: brute-force cosine for the hybrid verdict retriever — MAF-free, offline (D-C).
     # Upper bound is <2.3, NOT <3, and it is load-bearing twice over: numpy 2.3+ requires