feat(mcp): add index routing to search-records (RAAE-1606)

[vishal-bala]

Motivation

With a single MCP server now able to expose multiple logical index bindings (RAAE-1604) and advertise them via list-indexes (RAAE-1605), the search-records tool still implicitly resolved the sole binding. On a multi-binding server it had no way to say which index a query should run against. This change (RAAE-1606) makes that routing explicit while keeping the public contract backwards-safe for existing single-index callers.

The design goal is that v1 clients see no behavioral change: when exactly one binding is configured and the caller omits index, the request resolves to that binding exactly as before. Routing only becomes mandatory once ambiguity exists. Query construction, validation, pagination, filtering, and the configured search mode all remain owned by the selected binding — this ticket adds only the selection and a confirmation echo, not new query behavior.

Implemented changes

search-records gains an optional index argument naming the logical binding to query. Resolution flows through the shared resolve_binding routing introduced in RAAE-1604, so the three cases fall out consistently: an omitted index with one binding resolves to that binding; an omitted index with multiple bindings returns invalid_request; and an unknown id returns invalid_request. The resolved logical id is echoed back as the index field of the response payload so multi-index clients can confirm where a query actually ran. All downstream work (limits, schema, vectorizer, search config) continues to read from the resolved binding's runtime.

When multiple bindings are configured the tool description is ambiguous about fields, so instead of emitting per-field filter hints it now appends a short routing note directing the client to call list-indexes first and pass the chosen id as index. Single-binding servers keep their full schema-derived description unchanged.

Minor additional changes:

• The FastMCP wrapper exposes index as a tool parameter so MCP clients can supply it.
• Unit coverage for default-to-sole-binding, named routing, unknown-id rejection, the wrapper param, and the ambiguous-schema description note.
• Integration coverage for a two-binding server: routing to each named binding, omitted-index rejection, unknown-id rejection, and single-binding echo.

Verification

• make format (isort + black) and mypy clean on changed files.
• Full MCP suite: 232 passed, 2 skipped (Redis-version-gated) across unit + integration.

Stacking

This PR targets feature/raae-1605-list-indexes so its diff stays scoped to search routing. Review/merge bottom-up: #629 → #630 → this PR.

🤖 Generated with Claude Code

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}