fix: error-raising handlers and HttpResponse::body Content-Type inference

[oboard]

Summary

Two fixes on this branch:

1. Allow request handlers to raise errors (existing commit)

• HttpHandler/Middleware/dispatch_http no longer require noraise, so handlers and middleware may raise checked errors.
• Unhandled errors are converted to responses: a default 500 handler, customizable via Mocket::on_error.
• Cancellation errors are re-raised rather than swallowed.
• Both JS and native backends route dispatch errors through the error handler.

2. Infer body responder Content-Type in HttpResponse::body/json

HttpResponse::body previously serialized only the responder output, so custom-status responses kept their status and body but emitted no Content-Type at all:

HttpResponse::new(BadRequest).body("Invalid JSON")   // 400, no Content-Type
HttpResponse::new(NotFound).body(@mocket.html(...))  // 404, no Content-Type

Contract (documented in doc comments): the body responder's default Content-Type is carried into the response only when no explicit Content-Type was set. Explicit headers take precedence, the response status is preserved, and no other responder effects (arbitrary headers, cookies, status) are merged. Implemented by probing the responder's options against a throwaway response and extracting only Content-Type — no public API change.

Tests

• New black-box responder_test.mbt: direct String/Json/Html responders, custom-status body values, HttpResponse::json, and explicit Content-Type overrides.
• Existing error_wbtest.mbt covers error-to-response conversion and on_error.
• moon test → 59 passed; moon check → clean.

🤖 Generated with Claude Code