fix(ext/runtime): return 500 instead of 502 for invalid handler response

[davidbirdsong]

What kind of change does this PR introduce?

Bug fix.

What is the current behavior?

When a serve() handler (main worker, event worker, or a user function) resolves with something that isn't a Response object, ext/runtime/js/http.js falls back to a bare 502 Bad Gateway with a generic "Bad Gateway" body.

502 implies edge-runtime received an invalid response from an upstream/gateway target. That's not what's happening here: the "handler" runs in-process, and the violation is edge-runtime's own contract (a handler must resolve to a Response) not being honored. Framing it as a gateway error also makes this failure indistinguishable from unrelated, real gateway-level 502s, which complicates 502 triage.

What is the new behavior?

• The fallback now returns 500 Internal Server Error instead of 502 Bad Gateway, which more accurately reflects that the fault is internal, not upstream.
• The response carries a new header, x-edge-runtime-error: invalid-handler-response, so this specific failure mode can be distinguished from other 500s and from unrelated 502s in logs/metrics without relying on status code alone.
• badGatewayError() is renamed to invalidHandlerResponseError() to match what it actually represents.

Additional context

No functional change to the "handler threw an exception" path (internalServerError(), still 500, unchanged) — this only affects the "handler resolved to a non-Response value" path.

[davidbirdsong]

This change is part of the following stack:

• fix(ext/runtime): return 500 instead of 502 for invalid handler response #720 ◀

_{Change managed by git-spice.}

[kallebysantos]

You're introducing a new header,
I believe we should use the sb-error-code or discuss to find an better edge-runtime error pattern