MCP: add full_text_search tool

[robfrank]

Part of #4859.

Motivation

Completes the lexical leg cleanly; SEARCH_INDEX(indexName, query) plus BM25 scoring (LSMTreeFullTextIndex, BM25Scorer) has query-syntax quirks models won't reliably reproduce. Lower standalone value than vector/hybrid — this issue exists mainly to complete the retrieval trio and to give hybrid_search (#4861) and future prompts a documented tool to reference. Justification: #1 ergonomic guardrail.

Note: ArcadeDB's full-text index is its own LSM-tree structure with BM25 scoring — Lucene is used only for tokenization/analysis, not as the storage/retrieval engine. Docs for this tool should say "BM25 full-text index," not "Lucene index."

Proposed design

• Tool name: full_text_search
• Input schema:

{
  "type": "object",
  "properties": {
    "database": {"type": "string"},
    "indexName": {"type": "string"},
    "queryText": {"type": "string"},
    "limit": {"type": "integer", "default": 10}
  },
  "required": ["database", "indexName", "queryText"]
}

• Output: {results: [{rid, bm25Score, properties}]}
• Permission gating: allowReads.
• Engine functions used: SQLFunctionSearchIndex (fulltext.searchIndex), LSMTreeFullTextIndex, BM25Scorer.

Acceptance criteria

• Correct BM25 score surfaced (not just rank order).
• Errors clearly when indexName is not a full-text index type.
• Registered in both transports; tests + docs.

Files to touch

server/src/main/java/com/arcadedb/server/mcp/tools/FullTextSearchTool.java (new), MCPHttpHandler.java, MCPStdioServer.java, tests, docs.

Dependencies

None required by others, but should land before/alongside #4861 for terminology consistency.

Effort estimate

S — thin wrapper over an existing, well-defined function.