Replace rubydex_mcp server with Ruby implementation

[st0012]

Summary

Adds a Ruby implementation of rubydex_mcp with a small internal MCP/JSON-RPC protocol layer.

The existing Rust MCP crate and build plumbing are left in place. If this PR is accepted, I'll remove it in a follow up PR.

Parity with the Rust MCP server

Matches the existing Rust MCP server for:

• tool names and schemas: search_declarations, get_declaration, get_descendants, find_constant_references, get_file_declarations, codebase_stats
• startup indexing behavior and indexing-in-progress / indexing-failed responses
• JSON payload shapes, pagination defaults and caps, kind filtering, exact/fuzzy search modes, relative path formatting, declaration details, descendants, file declarations, and stats
• constant-reference behavior for classes/modules/constants, with methods returning an empty reference list

Manually checked against rust/target/debug/rubydex_mcp using the same fixture and tool calls for the six tools.

Known difference:

• unresolved partial ancestors are not exposed by the current Ruby API, so the Ruby MCP server only reports resolved ancestors. The manual parity check confirmed this as the expected mismatch.

Follow-up work

• Remove the Rust MCP implementation in a separate PR.
• Open a follow-up PR for Bundler integration.

[vinistock]

FWIW, one of the things I regret in the LSP was using parse! instead of the non-raising version parse. It makes it more difficult to make backwards incompatible changes to accepted flags, even for development related stuff.

[vinistock]

Better to use absolute paths when possible.

Suggested change

	path = ARGV.fetch(0, ".")
	path = ARGV.fetch(0, Dir.pwd)

[vinistock]

So we don't have to keep adding to the list.

Suggested change

	require "rubydex/mcp_server/tools/codebase_stats_tool"
	require "rubydex/mcp_server/tools/find_constant_references_tool"
	require "rubydex/mcp_server/tools/get_declaration_tool"
	require "rubydex/mcp_server/tools/get_descendants_tool"
	require "rubydex/mcp_server/tools/get_file_declarations_tool"
	require "rubydex/mcp_server/tools/search_declarations_tool"
	Dir.glob("rubydex/mcp_server/tools/**/*.rb").each { |f| require f }

[vinistock]

Now I'm wondering if the reference to other language names will make it better or worse at picking up the MCP 😂

[vinistock]

Is this maybe a better fit for the individual tool descriptions?

[vinistock]

IMO, it would be easier to follow the architecture if we merged Server and State into a single object and kept things like error codes and convenience objects inside protocol.

[vinistock]

Can the MCP send asynchronous messages to the client like an LSP can? If so, we're making the same mistake we originally made in the LSP here: implementing a handle method that returns the response to the sent to the client.

That approach makes it really difficult to have a single operation (like a tool call) both send an asynchronous notification and return a response.

That's why in the LSP we have an outgoing queue with a dispatcher thread. Any request/notification can enqueue as many messages as desired to be sent to the client.

[vinistock]

Do we need to check if it's string or symbol? If we control the JSON parsing, we should be able to use symbolize_names: true and standardize everything on symbols.

[vinistock]

Instead of an array, we should probably use a hash and make this a simple lookup.

[vinistock]

Is this using JSONRPC? The separator should be \r\n\r\n and not a single line. So you need something like gets("\r\n\r\n"). And the first line you get is the content length, so after the gets you need to read the specified number of bytes.

For example, something like this:

headers = io.gets("\r\n\r\n")
raise unless headers

length = headers[/Content-Length: (\d+)/i, 1]
raise unless length

raw_message = io.read(length)
message = JSON.parse(raw_message)