fix(web): add explicit headers following prior normalization (#4951)

These changes add explicit `Content-Type` headers to direct (via `native` interceptor)
authentication requests after changes made in [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931) that modified how `Content-Type`
headers are handled in the `relay` plugin.

In [issue #4905](https://github.com/hoppscotch/hoppscotch/issues/4905), that was about Hoppscotch Agent and Native interceptor inconsistently
handling `Content-Type` headers. The issue had two main manifestations,
duplicate headers - when overriding the `Content-Type` header in the UI or using OAuth2 authentication, the agent
would send multiple `Content-Type` headers to the web server. This caused undefined behavior
and often 400 errors for backends that don't accept duplicate headers.
And inconsistent overrides - even when the content type was explicitly set (for example to
`application/json;v=2`), the agent/native would inconsistently apply this override. Server
logs revealed that roughly 50% of requests would use the correct override value, while the
others would revert to the default `application/json`.

The two-part solution implemented first in [PR #4911](https://github.com/hoppscotch/hoppscotch/pull/4911) addressed the duplicate headers issue
by implementing header normalization before final relay. This prevented duplicate headers
with different casing from being sent and [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931) then resolved the inconsistent override
behavior by removing the automatic `Content-Type` header insertion in the `ContentHandler`
component. As explained in the PR description, this was a temporary workaround until we
implement a HTTP/2-compliant solution with proper normalization.

While the fixes in PR #4911 and #4931 correctly resolved the header inconsistency issues
for general API requests, they introduced a new problem: **requests that previously relied
on the automatic `Content-Type` insertion now have no `Content-Type` header at all**.

This mainly affects direct calls around authentication flows in the desktop module, which
were using the `content.json()` functionality without explicitly setting `Content-Type`
headers, relying on the automatic insertion that has now been removed.

These changes add the now-required explicit `Content-Type` headers to three
authentication-related API calls in the desktop platform module:

- **The initial user details GraphQL query**:
```javascript
headers: {
  Authorization: `Bearer ${accessToken}`,
  "Content-Type": "application/json",
},
```

- **The magic link email submission endpoint**:
```javascript
headers: {
  "Content-Type": "application/json",
},
```

- **The token verification endpoint**:
```javascript
headers: {
  "Content-Type": "application/json",
},
```

This will make sure that authentication flows continue to work properly with the native
interceptor after the header handling changes.

As noted in [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931), this is considered a **temporary solution**. The plan is to revisit the
content-type handling when we implement a more comprehensive HTTP/2-compliant header
normalization system in the kernel layer.

While HTTP/1.1 headers are case-insensitive
per [RFC 7230](https://tools.ietf.org/html/rfc7230), inconsistent handling across server implementations can treat differently-cased
variations as distinct headers. HTTP/2 ([RFC 7540](https://tools.ietf.org/html/rfc7540)) mandates converting all header field
names to lowercase, which would prevent these issues altogether. In such cases, relying
fully on `MediaType` interface from the kernel will help handling these edge-cases.

packages/hoppscotch-selfhost-web/src/platform/auth/desktop/index.ts

@@ -97,6 +97,7 @@ async function getInitialUserDetails(): Promise<
       version: "HTTP/1.1",
       headers: {
         Authorization: `Bearer ${accessToken}`,
+        "Content-Type": "application/json",
       },
       content: content.json({
         query: `query Me {
@@ -164,6 +165,9 @@ export async function setInitialUser() {
   isGettingInitialUser.value = true
   const res = await getInitialUserDetails()
 
+  // NOTE: This is required for further diagnosis,
+  //       to be removed after patch confirmation.
+  console.info("Auth response structure:", JSON.stringify(res, null, 2))
   if ("error" in res) {
     await setUser(null)
     isGettingInitialUser.value = false
@@ -258,6 +262,9 @@ async function sendMagicLink(email: string) {
     url: `${import.meta.env.VITE_BACKEND_API_URL}/auth/signin?origin=desktop`,
     version: "HTTP/1.1",
     method: "POST",
+    headers: {
+      "Content-Type": "application/json",
+    },
     content: content.json({ email }),
   })
 
@@ -460,6 +467,9 @@ export const def: AuthPlatformDef = {
       url: `${import.meta.env.VITE_BACKEND_API_URL}/auth/verify`,
       version: "HTTP/1.1",
       method: "POST",
+      headers: {
+        "Content-Type": "application/json",
+      },
       content: content.json({
         token: verifyToken,
         deviceIdentifier,