Expose an MCP surface over a shared XTable tool registry

### Feature Request / Improvement

Expose XTable's operations as MCP tools, over a single shared tool registry, so any MCP client can drive a conversion without XTable shipping product-specific integrations.

## Design

Follow the pattern `apache/hudi` used in `hudi-agent-gateway`: define each tool once in a registry, and let every surface expose it. In their words, one registration reaches the agent loop, the MCP server, the tool-listing endpoint and the invocation log.

For XTable that means the MCP surface sits on the same tool layer as the REST service (#666), not beside it. Two APIs with drifting behaviour is the outcome to avoid.

## Proposed v1 tools

- `validate_config` — check a `datasetConfig` against the generated schema and return actionable errors.
- `inspect` — given a path, report the detected format, schema, partitioning and commit or snapshot count. PR #830 makes the detection part nearly free.
- `convert` — run a sync and return the structured result.
- `diagnose` — classify a failure into a named cause (missing format jar, partition-spec mismatch, unsupported type, permission) and give the remedy.
- `verify` — compare source and target after a conversion and summarise equivalence.

## Guardrails

Hudi's v1 tools are read-only queries. XTable's central operation writes metadata, so this needs more care than their case did:

- `convert` defaults to dry-run and requires an explicit flag to write.
- Every invocation logged as structured JSON.
- Result truncation and time limits, so a large table cannot flood a model's context.
- No credentials in tool arguments.

## Open questions

- Language. Hudi chose Python for the agent layer despite being a JVM project, because that ecosystem is Python-first. XTable's tools wrap XTable's own Java code and need no third-party agent framework, so Java with the MCP Java SDK is also defensible. Worth deciding deliberately.
- Whether this is a module in this repo or a separate deployable, which depends on how #666 is packaged.

## Depends on

The agent-legible CLI and the generated config schema, both linked from the parent issue. `convert` and `validate_config` are thin wrappers once those exist.

### Are you willing to submit PR?

- [x] Yes I am willing to submit a PR!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)

Start by reading the agent-legible CLI and generated config schema referenced as dependencies, then compare the REST-service direction in #666 and detection work in #830. Resolve the Java-versus-Python and module-versus-deployable questions before defining the shared registry. Done means the proposed MCP tools, guardrails, and structured results have an agreed implementation boundary.

Written by the indexing model from the issue text.