Validate response schema

[rgambee]

This validates that the response schema passed to the MCP tools is valid JSON schema. It needs to look like

"response_schema": {
  "type": "object",
  "properties": {
    "population": {"type": "string"},
    "year": {"type": "string"}
  }
}

This is not allowed

"response_schema": {
  "population": "string",
  "year": "string"
}

To be clear, the second format has never been allowed. But now the MCP server will yell at you if you try to use it. Previously it would have silently turned your schema into the empty one, which meant you'd get no results.

I also updated the documentation a bit to try to clarify this.

[sentry]

Bug: The new _validate_response_schema function allows underscore-prefixed field names, but Pydantic's create_model later silently ignores them, leading to unexpected data loss.
_{Severity: MEDIUM}

Suggested Fix

Update the _validate_response_schema function to iterate through the properties in the schema and explicitly raise a ValueError if any field name starts with an underscore, similar to how other schema validations are performed.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: everyrow-mcp/src/everyrow_mcp/server.py#L992-L1006

Potential issue: The new validation function `_validate_response_schema` does not
prohibit field names that start with an underscore. While the old code explicitly
skipped these fields, the new logic allows them to pass validation. However, the
downstream call to Pydantic's `create_model` in `_schema_to_model` will silently ignore
any fields prefixed with an underscore, only issuing a `RuntimeWarning`. This
discrepancy means a schema with a field like `_internal_id` will be considered valid,
but the corresponding data will not be captured, resulting in silent data loss.

_{Did we get this right? 👍 / 👎 to inform future reviews.}