fix(reins): give every LightRAG call a deadline (CLEAN-101)

[maksymhryzodub-prog]

LightragHttpClient makes thirteen HTTP calls. Two carried a deadline — /health at 2s and the external URL fetch in ingestUrl at 15s. The other eleven, /query among them, passed no signal at all, so a LightRAG that accepts the connection and never answers held the request open for as long as the caller would wait.

For an agent that caller is the MCP client, whose 60s default was the only bound anywhere in the chain:

15:35:12  llm -> Knowledge__query_knowledge
15:36:12  MCP error -32001: Request timed out
15:36:52  llm -> Knowledge__query_knowledge
15:37:52  MCP error -32001: Request timed out

Exactly 60.002s both times, against a knowledge base reporting Ready with 746/746 indexed. The agent learns only that something, somewhere, did not answer — not which endpoint, not which base, not for how long — and three of those in a row exhaust maxConsecutiveErrors and end the turn, about three minutes of wall clock for no information.

Every call now goes through fetchWithDeadline, which attaches the signal and converts an abort into a LightragClientError naming the endpoint and the limit. Reads are bounded at 45s, below the MCP client's 60s, so the API fails first and says something useful. Writes get 180s because indexing legitimately runs long and nothing on that path is reached through MCP. /health keeps its own 2s: it is a liveness probe and must stay fast. A non-timeout error still propagates unchanged rather than being dressed up as a deadline, which would send a reader hunting for a slow instance instead of a missing one.

This does not make an unresponsive LightRAG answer. It stops the platform from hiding that behind a generic timeout.

Claude-Session: https://claude.ai/code/session_011B9tuWEQvYg5YQY9SQZN2u