search_nodes never returns core (n8n-nodes-base) nodes; source filter has no effect

Description

search_nodes never returns core (n8n-nodes-base.*) nodes for common queries, even when the exact core node clearly exists in the bundled database (confirmed via get_node). This makes the documented discovery workflow ("search_nodes -> get_node -> validate_node") unusable when the exact node type isn't already known, since results are 100% community packages regardless of query, mode, or source filter.

Environment

• n8n-mcp version: 2.84.1 (via npx -y n8n-mcp)
• MCP transport: stdio
• n8n instance: 2.38.7 (local, Docker), API connected and healthy (n8n_health_check reports apiConfiguration.status.connected: true)
• OS: Windows 11 (via Git Bash)

Steps to reproduce

1. search_nodes({query: "webhook", source: "core", limit: 20}) -> all 20 results have isCommunity: true, category: "Community". No n8n-nodes-base.webhook in the results.
2. search_nodes({query: "HTTP Request", source: "core"}) -> same pattern, all community.
3. search_nodes({query: "code", source: "core"}) -> same pattern.
4. search_nodes({query: "No Operation"}) (no source filter, default "all") -> 10 results, none related to the query at all (random high-download community packages: Brazilian bank API, ComfyUI nodes, etc.) - no n8n-nodes-base.noOp.
5. Confirm the core node is actually indexed: get_node({nodeType: "n8n-nodes-base.noOp", detail: "minimal"}) -> succeeds, returns correct data (displayName: "No Operation, do nothing", package: "n8n-nodes-base").

Expected behavior

• source: "core" should restrict results to n8n-nodes-base package nodes only.
• A query like "webhook" or "No Operation" should surface the matching core node with high relevance, since get_node proves it's indexed correctly.

Actual behavior

• The source parameter appears to have no effect on the returned set - it's identical whether omitted, "all", or "core".
• Full-text relevance ranking also appears broken independent of the source bug: search_nodes({query: "No Operation"}) returns 10 results with no semantic relation to the query text at all.
• get_node (direct type lookup) is unaffected and returns correct data, so this looks isolated to the search_nodes query/ranking path, not the underlying node database.

Impact

Any workflow-building session that doesn't already know exact n8n-nodes-base.* type strings cannot discover them via search_nodes - every search is drowned in community packages.