fix(mcp): keep zero-result lookups out of isError

[fahreddinozcan]

Stops resolve-library-id and query-docs from flagging "nothing matched" as a tool execution error, which upstash#2989 currently does despite its changeset promising otherwise.

• The API reports zero results as a 404 carrying no_libraries_found / no_relevant_snippets. parseErrorResponse discarded that code and kept only the message, so every 404 became isError: true.
• parseErrorResponse now returns { message, isError }. The status fallback moves to a helper so its branches stay byte-identical.
• SearchResponse gains isError, so resolve-library-id stops inferring failure from the presence of display text.
• Benign outcomes are no longer logged to stderr as errors.
• Adds coverage for both empty-result codes, library_not_found on the same 404 status, and searchLibraries, which had no tests.

library_not_found stays an error. Error text is unchanged everywhere, so the model still sees "Try a different search term".

Why

The spec does not address empty result sets. It says isError is for tool calls that failed, and also that it exists so the LLM can self-correct, which cuts both ways. The tiebreaker is what clients do: the v2 SDK's own callTool example returns early on isError without showing content. Leaving the flag unset is safe under every host because the message text already tells the model to retry, whereas setting it risks swallowing that guidance on the most common benign outcome.

Verified

typecheck, lint, build, test (54/54). Live against the real Context7 API over stdio:

case	before	after
zero search matches	true	unset
query matched no snippets	true	unset
bad library id	true	true
valid search / valid docs	unset	unset
unreachable API, all calls	true	true