[Security] Harden dev proxy invalid path response against content sniffing

[github-actions]

WHY are these changes introduced?

The reverse HTTP proxy used during app dev echoes the requested path back to the client when no routing rule matches it. The response is sent without an explicit content type, so browsers fall back to content sniffing and may interpret the reflected path as HTML. That makes the local dev server vulnerable to a reflected content-injection issue in its own origin, reachable from any page the developer happens to have open.

WHAT is this pull request doing?

Send the "invalid path" error with an explicit text/plain; charset=utf-8 content type and X-Content-Type-Options: nosniff, so the reflected path can never be treated as markup. The status code and message are unchanged, and a regression test covers the new response headers.

How to manually test your changes?

Run shopify app dev and request a path that no proxy rule matches on the proxy port, for example curl -i http://localhost:<proxy-port>/nowhere. The 500 response should carry Content-Type: text/plain; charset=utf-8 and X-Content-Type-Options: nosniff, with the same body as before.

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add