Fixes ERR_TLS_CERT_ALTNAME_INVALID when using Next.js with Bun.

When running Next.js under Bun, proxying via a catch-all route failed with ERR_TLS_CERT_ALTNAME_INVALID. Bun's TLS validation is stricter than Node's and will reject requests when the Host header does not match the target URL's hostname.

Root cause:
Our proxy forwarded the original request headers including host: localhost:3000 (from local dev server) to the upstream Convex URL. This mismatched host header triggered Bun's TLS altname check.

Example of forwarded headers prior to this change (from a local dev server):

{
    host: "localhost:3000",
    "user-agent":
        "Mozilla/5.0 (X11; Linux x86_64; rv:144.0) Gecko/20100101 Firefox/144.0",
    accept: "*/*",
    "accept-language": "en-US,en;q=0.5",
    "accept-encoding": "gzip, deflate, br, zstd",
    referer: "http://localhost:3000/auth/login",
    connection: "keep-alive",
    cookie: "xxx",
    "sec-fetch-dest": "empty",
    "sec-fetch-mode": "cors",
    "sec-gpc": "1",
    "sec-fetch-site": "same-origin",
    priority: "u=4",
    "x-forwarded-host": "localhost:3000",
    "x-forwarded-port": "3000",
    "x-forwarded-proto": "http",
    "x-forwarded-for": "::ffff:127.0.0.1",
}

This PR addresses this issue and removes host header before forwarding to Convex and lets fetch set the correct host based on the Convex URL.

Notes:
Other hop-by-hop headers could also be stripped but they have correct values for forwarded requests. They do not cause any issues though.

Links:

• First time I experienced this issue
• Found the issue to be Bun related
• After some digging found the root cause
• MDN host header

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.