fix(auth): build verify-email redirects from the configured public origin

Redirects were built relative to `request.url`, which behind a reverse proxy
resolves to the container-internal address. Verification succeeded but the
browser was sent to localhost:3000, so users saw a connection error instead of
the "email verified" confirmation.

Add getPublicOrigin() (NEXTAUTH_URL, then NEXT_PUBLIC_APP_URL, falling back to
the request origin for local development) and use it for every verify-email
redirect. The legacy GET redirect in the watch session route had the same
defect and is fixed alongside it.

lib/request-origin.ts

@@ -16,6 +16,26 @@ function getConfiguredOrigins(): string[] {
     .filter((value): value is string => value !== null);
 }
 
+/**
+ * Origin to build user-facing redirects from.
+ *
+ * Behind a reverse proxy (Docker deployments) `request.nextUrl.origin` is the
+ * container-internal address (`localhost:3000`), so redirecting relative to the
+ * request URL sends the browser to a dead host. Prefer the operator-configured
+ * public origin and fall back to the request origin for local development.
+ */
+export function getPublicOrigin(request: NextRequest): string {
+  const configured = [process.env.NEXTAUTH_URL, process.env.NEXT_PUBLIC_APP_URL];
+
+  for (const value of configured) {
+    if (typeof value !== 'string' || value.trim().length === 0) continue;
+    const origin = normalizeOrigin(/^https?:\/\//i.test(value) ? value : `https://${value}`);
+    if (origin) return origin;
+  }
+
+  return request.nextUrl.origin;
+}
+
 export function getAllowedRequestOrigins(request: NextRequest): Set<string> {
   const origins = new Set<string>();