fix(mcp): guard JSON-RPC handler against non-dict body

[CodeLine9]

Bug

handle_jsonrpc assumes data is always a dict. Sending a top-level JSON integer, string, list, or null triggers TypeError from the in operator, which surfaces as HTTP 500 instead of the spec-correct -32600 Invalid Request.

Fix

Added an isinstance(data, dict) guard before the "jsonrpc" not in data check. Non-dict payloads now return 400 with Invalid Request: expected JSON object.

Closes #790

[CodeLine9]

Thanks for the review! Ready to merge when you get a chance.

[CodeLine9]

Closing — focusing on other priorities.

[github-actions]

Summary

Small, correct bug fix that resolves #790 — handle_jsonrpc now guards against non-dict top-level JSON (integer, string, list, null) before the in and .get calls that previously blew up with TypeError/AttributeError and surfaced as HTTP 500. The response shape mirrors the adjacent JSON-RPC validation block, which keeps error semantics consistent for clients.

Issues Found

🟢 Minor — No regression test added (tests/mcp/test_mcp_http_validation.py)

test_error_invalid_jsonrpc at tests/mcp/test_mcp_http_validation.py:226 covers the wrong-version case ({"jsonrpc": "1.0", ...}) but nothing exercises the non-dict body path this PR fixes. A follow-up adding a parallel case (data=42, data="foo", data=[1,2], data=None) would prevent regression if this dispatcher ever gets refactored.

Suggested shape (to add after the existing test_error_invalid_jsonrpc):

@test("Error Handling - Non-dict JSON-RPC body", "Test top-level non-object JSON")
def test_error_nondict_jsonrpc():
    for body in (42, "foo", [1, 2], None):
        response = make_request("/", method="POST", data=body)
        assert "error" in response, f"Should return error for {body!r}"
        assert response["error"]["code"] == -32600, "Should be Invalid Request"
    return True

Not blocking — the fix itself is trivial and the behavior is obvious.

Strengths

• Consistent error envelope (src/gaia/mcp/mcp_bridge.py:625-635): the new branch reuses the exact HTTP 400 + -32600 Invalid Request + "id": None shape as the adjacent version check at line 637, so clients see one coherent error format regardless of which validation failed.
• Correct JSON-RPC code choice: -32600 (Invalid Request) is right here since the body did parse successfully — it just isn't a valid Request object. -32700 (Parse error) would have been wrong.
• Tight scope: 11 added lines, one file, one concern. No drive-by refactors or unrelated cleanups — exactly what a bug fix should look like.

Verdict

Approve. Already merged; logging the minor test-coverage nit above as a follow-up suggestion rather than a blocker.