fix(auth): pin Supabase auth cookie name to public URL across clients

@supabase/ssr derives the auth cookie storage key from the hostname of the URL
it is given (sb-<sub>-auth-token). After routing server-side clients at the
internal host (kong-prod), the server looked for sb-kong-prod-auth-token while
the browser had set sb-api-auth-token, so server-side getUser() never found the
just-established session and bounced the user off the MFA challenge back to
/login. Pin every client (browser, server, middleware) to the name derived from
NEXT_PUBLIC_SUPABASE_URL via a shared helper so the namespace stays consistent
regardless of which API endpoint the client talks to.

lib/supabase/cookie-name.ts

@@ -0,0 +1,18 @@
+/**
+ * The auth cookie name that @supabase/ssr would derive from the PUBLIC Supabase
+ * URL (e.g. `sb-api-auth-token` for `https://api.linumiq.net`).
+ *
+ * Server-side clients talk to Supabase over the internal Docker URL
+ * (SUPABASE_INTERNAL_URL, e.g. `http://kong-prod:8000`) to bypass the edge rate
+ * limiter. But @supabase/ssr derives the cookie storage key from whatever URL
+ * it is given, so a server client pointed at the internal host would look for
+ * `sb-kong-prod-auth-token` while the browser set `sb-api-auth-token` — the
+ * session cookie would never be found and getUser() would return null. Pinning
+ * every client to this single, public-URL-derived name keeps the browser and
+ * server cookie namespaces in sync regardless of the API endpoint used.
+ */
+export function supabaseAuthCookieName(): string {
+  const publicUrl = process.env.NEXT_PUBLIC_SUPABASE_URL!;
+  const ref = new URL(publicUrl).hostname.split('.')[0];
+  return `sb-${ref}-auth-token`;
+}