fix(query): don't swallow cursor:eval errors as HTTP 200 'Invalid context-item' (regression in 0.9.7)

[joewiz]

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

Regression fix for 0.9.7. Spotted while running eXide develop HEAD's cypress suite against eXist 7 beta3 + existdb-openapi 0.9.7: two specs (query_error_display_spec, query_error_structured_spec) failed because the existdb-openapi /api/query endpoint was swallowing every error from cursor:eval as HTTP 200 { error: "Invalid context-item: …" }.

Root cause

The try/catch I added in #41 (context-item support) was too broad:

try {
    ...cursor:eval($expression, $mlp, $context-item)...
} catch query:context-path-not-found {
    map { "error": $err:description }
} catch * {
    map { "error": "Invalid context-item: " || $err:description }    -- ← catches EVERYTHING
}

A user's //does-not-exist:foo (an XPST0081 namespace error from cursor:eval) came back as:

HTTP 200
{ "error": "Invalid context-item: ... No namespace defined for prefix does-not-exist:foo" }

Two contracts broken at once:

1. Wrong label. The context item was fine; the user's XQuery referenced an undeclared prefix. Calling it a context-item failure misdirects the user.
2. Wrong status. eXide's #run handler (src/eXide.js:937) detects query errors via if (!response.ok). HTTP 200 → it thinks the query succeeded, tries to read data.cursor (undefined), and the error pill / panel never lights up. That's the symptom the eXide cypress specs were catching.

Fix

• The parse-xml call moves into its own try/catch inside a new private helper query:resolve-context-item. That's the only place the "Invalid context-item:" prefix is now applied.
• Resolution returns a {status, error} map for the two failure modes — 404 for a missing context-path, 400 for malformed context-item XML — and the caller wraps it in roaster:response(status, ...) so the HTTP code matches.
• cursor:eval errors are no longer caught. They propagate to Roaster, which renders the standard XPathException → JSON shape ({code, description, line, column, module, value}) with an HTTP 500. That's exactly what eXide's editor.evalError handler already expects.
• modules/api.json updated to declare 400, 404, and 500 responses so Roaster doesn't fall back to XML serialization on them.

After the fix

//does-not-exist:foo  →  HTTP 500
{
  "code": "err:XPST0081",
  "description": "It is a static error if a QName ... No namespace defined for prefix does-not-exist:foo ...",
  "line": 1, "column": 3, "module": null, "value": null
}

1 + "a"               →  HTTP 500 with err:XPTY0004 + full structured fields

<not-well-formed>     →  HTTP 400 { "error": "Invalid context-item: ..." }   (correctly labelled this time)

/db/nonexistent.xml   →  HTTP 404 { "error": "context-path not found: ..." }

1 to 3                →  HTTP 200 { "cursor": "...", "items": 3, ... }   (unchanged)

Verified

• 33 query.cy.js tests pass on existdb-openapi (3 new regression tests covering HTTP-status-on-error and the no-rewrapping behaviour).
• eXide develop HEAD's full cypress suite: 260 passing, 0 failing, 2 intentional skips — up from 258/262 before the fix. The two failing specs (query_error_display_spec, query_error_structured_spec) both pass now.
• PMD clean.

Apologies

This was a regression I shipped in 0.9.7. Cutting a 0.9.8 once this lands.