Feature request: find_remote_tools - implement semantic/intent-based filtering

`find_remote_tools` accepts an `intent` parameter ("Natural-language description of what the caller is looking for") but it is a no-op: the handler logs it at debug level and ignores it (`internal/node/mcp_handlers.go`). The tool description and JSON schema already advertise it as "reserved for future semantic ranking".

**Current behavior**

Only structural filters work: `peer_id`, `service_name`, and `tool_name` (exact match). An agent that doesn't know a tool's exact name must list everything and scan descriptions itself.

**Feature request**

Make `intent` actually filter/rank results. When set, match it against tool names and descriptions and return results ordered by relevance (or filtered to relevant ones), so a caller can ask e.g. `intent: "review a pull request"` and get `mcp://code-reviewer/review_pr` near the top without knowing the name.

Possible directions, from simplest to heaviest:

1. Lexical matching (substring/keyword overlap against name + description) — no new dependencies.
2. Embedding-based ranking, e.g. via an inference service already hosted on the mesh.

**Notes**

- Should compose with the existing filters (`peer_id`, `service_name`).
- If `intent` is set together with `tool_name`, the exact-name lookup should probably still win.
- No API change needed: the parameter and its schema already exist, so this is backward compatible.

Start in internal/node/mcp_handlers.go at the find_remote_tools handler and trace how intent and the existing peer_id, service_name, and tool_name filters are processed. Decide on a relevance approach, then verify that intent returns or ranks matching names and descriptions, composes with existing filters, and preserves exact-name lookup behavior.

Written by the indexing model from the issue text.