[bugfix] RESTServer: set Content-Type for JSON results

[joewiz]

[This PR was co-authored with Claude Code. -Joe]

Summary

The REST server's JSON result writer (RESTServer.writeResultJSON) never set the response Content-Type. As a result, query results serialized as JSON — a POST <query method="json"> (the JSON result envelope used by the query sandbox in eXide and other clients) — were returned without a Content-Type header, and output:media-type was silently ignored on that path. Clients then received JSON under the wrong media type, which is the "XML Parsing Error in console" class of failure (browsers try to parse a JSON body as XML).

The XML writer (writeResultXML) already honors output:media-type and sets Content-Type; the JSON writer simply never did.

Fix

In writeResultJSON, set the response Content-Type before the output stream is opened (mirroring the XML path):

• if the response already carries a Content-Type, leave it;
• otherwise default to application/json, but honor an explicit output:media-type when the query set one to something other than the XML default (so a custom type like application/vnd.api+json is respected).

The logic lives in a small private helper (setJsonResponseContentType) so the (already large) writeResultJSON method gains no extra branching. A reusable MimeType.JSON_TYPE constant (application/json) is added alongside the existing XML_TYPE/HTML_TYPE/TEXT_TYPE.

Tests

Two new cases in RESTServiceTest:

• postQueryJsonContentType — a method="json" query returns Content-Type: application/json.
• postQueryJsonExplicitMediaType — an explicit media-type is honored rather than overridden by the application/json default.

Both pass; the change introduces no new PMD findings (the touched method drops back under the NPath threshold).

Context

This is an independent eXist-core bug that surfaced in discussion of the eXide login work (the same underlying gap behind eXist-db/eXide#253). It's worth fixing on its own because the JSON result envelope is used by any REST/JSON client, not just eXide — eXide's own login has separately moved onto Roaster. A companion effort adds reusable Accept-header content negotiation to the request module; this PR is just the narrow Content-Type bug and stands alone.