Surface grep_search file-name matching + matchedByName flag (#375)

[rodion-m]

Summary

Pairs with CodeAlive-AI/backend#376. The backend's grep_search now also matches file names/paths for literal queries and flags name-only hits with matchedByName: true. This MCP-side change surfaces that signal to LLM agents — previously the transformer dropped the field entirely, so the new behaviour would have reached the API but not any MCP consumer.

Changes

• response_transformer.transform_grep_response forwards matchedByName into the MCP dict output, only when the backend set it (mirrors System.Text.Json's WhenWritingNull wire semantics so content-match responses stay byte-identical to the pre-change shape).
• grep_search tool docstring updated:
  • description mentions literal file-name matching
  • explains the Form.xml use case (issue #375)
  • documents the matchedByName contract: empty matches, location points at line 1 as a file-level reference, must not be interpreted as a content match
  • flags the Phase 1 limitation that regex=true still only searches content
• README.md one-line summary of grep_search extended accordingly.
• New test test_grep_forwards_matched_by_name_flag asserts name-only hits surface the flag and content hits do not.

Test plan

• 17/17 response_transformer tests pass (16 pre-existing + 1 new)
• 249/249 full MCP unit suite passes
• Smoke-test after rebuild: connect any MCP client (Claude Code, Cursor), invoke grep_search("Form.xml") against the BITERP workspace, verify the new tool description renders and that name-only hits carry matchedByName: true

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request enhances the grep_search tool by adding support for literal file-name and path matching alongside existing content searches. The changes include updates to the tool's documentation, the response transformer to handle a new matchedByName flag, and a new test case to verify this behavior. A review comment points out a discrepancy in the grep_search docstring, suggesting that it should refer to startLine instead of location.line to accurately reflect the field names in the transformed output.

[gemini-code-assist]

The docstring refers to location.line, but the transform_grep_response function (via _build_result_dict) flattens the nested backend structure into startLine and endLine in the final output. To avoid confusing LLM agents that rely on this documentation to parse the tool response, the docstring should use the actual field names present in the transformed JSON.

Suggested change

	`matches` is empty and `location.line` defaults to 1 as a
	file-level reference — do NOT interpret `location.line` as an
	`matches` is empty and `startLine` defaults to 1 as a
	file-level reference — do NOT interpret `startLine` as an