fix: prevent user ID spoofing by stripping client-supplied 'g' header in withMobileAuth

[MehranKhn]

Problem

The withMobileAuth middleware in /src/middleware.ts had two vulnerabilities:

Vulnerability 1 — Auth-Key not validated:
The original code only checked if Auth-Key header existed, not its value:

if (req.headers.get('Auth-Key')) {  // ← any value passed!
  return NextResponse.next();
}

Vulnerability 2 — Client-supplied g header not stripped:
When Auth-Key matched, the middleware called NextResponse.next()
without stripping the incoming headers. This meant an attacker could:

1. Send a valid Auth-Key
2. Attach their own g: {"id": "admin-user-id"} header
3. The endpoint blindly trusted it:

// route.ts — trusted client-supplied g as if server set it
const user: { id: string } = JSON.parse(request.headers.get('g') || '');

Attack looked like this:

curl -H "Auth-Key: validkey" \
     -H 'g: {"id": "some-admin-id"}' \
     https://site.com/api/mobile/courses/123

---

Fix

const authKey = req.headers.get('Auth-Key');

if (authKey && authKey === process.env.APPX_AUTH_KEY) {
  const newHeaders = new Headers(req.headers);
  newHeaders.delete('g');  // ← strip spoofed g header
  return NextResponse.next({
    request: { headers: newHeaders },
  });
}

Two things fixed:

1. Auth-Key value is now validated against process.env.APPX_AUTH_KEY
2. Client-supplied g header is deleted before forwarding the request

The JWT path was already safe since it overwrites g with
newHeaders.set('g', JSON.stringify(payload)) — a server-verified value.

---

Security Impact

Before fix → attacker could access any user's course data by spoofing their ID
After fix → g header is always either absent or server-generated, never client-trusted

Fixes #1924