Fix: /api/context route in main thread

[rcasaleiro]

Problem

unity_get_project_context always fails with HTTP 500, so the Project Context
feature never returns anything.

Cause

The bridge handles every request on a background ThreadPool thread:

ThreadPool.QueueUserWorkItem(_ => HandleRequest(context));

The /api/context routes call GetContextResponse() directly on that thread, and it
reads EditorPrefs (ContextEnabled / ContextPath) — a main-thread-only Unity API.
So every request throws and returns 500:

GetBool can only be called from the main thread.
  at MCPSettingsManager.get_ContextEnabled()
  at MCPContextManager.GetContextResponse()
  at MCPBridgeServer.HandleRequest()

Fix

Run the two context routes through ExecuteOnMainThread(...) — the same helper every
other synchronous route already uses. One-file change; no other endpoints affected.

Testing

Tested locally with a new project with only three docs in under Assets/MCP/Context/: unity_get_project_context returned 500 before
the change and returns the full content after, for both the all-categories and
single-category calls.

[francoios]

Thanks @rcasaleiro — spot-on root cause. The /api/context main-thread fix was re-implemented on main (merged via #21): both context routes now go through ExecuteOnMainThread like every other sync route, so the EditorPrefs read no longer returns HTTP 500 from a ThreadPool thread. Verified live (the exact call that 500'd now returns a graceful payload). Credited in the changelog.

Closing as resolved by the forward-port. 🙏