Make the session cookie name configurable for a staging deployment

Groundwork for testmodul.qrmaster.net, a second stack running the `test` branch on a real
qrmaster.net subdomain.

Production scopes its session cookie to .qrmaster.net, so the browser sends it to every
subdomain including staging. With both environments naming the cookie `userId`, the
browser holds two cookies of the same name and cookies.get() picks one arbitrarily -
staging logins would look randomly signed-out. AUTH_COOKIE_NAME lets staging pick
`userId_test` instead. Production keeps the `userId` default; changing it there would
invalidate every existing session.

Wired getAuthCookieName() into the six places that named the cookie literally. The account
deletion route now expires both the host-only and the domain-scoped variant like the logout
route already does, instead of a single cookies().delete() that would leave the other one
behind.

NEXT_PUBLIC_WWW_URL and NEXT_PUBLIC_APP_URL become build ARGs so the same image can be
built pointing at the staging host - the defaults keep a plain production build byte
identical to before. Like COOKIE_DOMAIN these must exist at build time, because process.env
is inlined into the Edge middleware bundle.

robots.ts now serves Disallow-all unless NEXT_PUBLIC_INDEXABLE is true. Staging otherwise
returns the production robots.txt and invites crawlers to index a duplicate of www.

docker-compose.test.yml is the staging overlay. Two things it must get right, both verified
against `docker compose config`:

- db and redis need `networks: !override`. Compose MERGES the networks mapping from the base
  file, and since qrmaster-network is external and shared, a plain list left them attached
  to it - `db` would then resolve to two containers and staging could read and write the
  production database.
- The web entrypoint is replaced so `prisma migrate deploy` never runs. prisma/migrations
  stopped in April 2026 and the schema has moved on through manual SQL since, so applying
  them to a fresh database would build a stale schema. Staging gets its schema from
  `pg_dump --schema-only` against production instead.

Verified: tsc clean, production build succeeds, and the merged compose config confirms
staging keeps db/redis off the shared network while production resolves unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/app/(main)/api/user/delete/route.ts

@@ -1,5 +1,5 @@
 import { NextRequest, NextResponse } from 'next/server';
-import { cookies } from 'next/headers';
+import { appendExpiredCookies, getAuthCookieName } from '@/lib/cookieConfig';
 import { getSessionUserId } from '@/lib/session';
 import { db } from '@/lib/db';
 import { stripe } from '@/lib/stripe';
@@ -73,10 +73,13 @@ export async function DELETE(request: NextRequest) {
       where: { id: userId },
     });
 
-    // Clear auth cookie
-    cookies().delete('userId');
+    // Clear auth cookie. Same reasoning as the logout route: both the host-only and the
+    // domain-scoped variant have to be expired, otherwise the survivor keeps a session
+    // pointing at a user row that no longer exists.
+    const response = NextResponse.json({ success: true });
+    appendExpiredCookies(response.headers, [{ name: getAuthCookieName(), httpOnly: true }]);
 
-    return NextResponse.json({ success: true });
+    return response;
   } catch (error) {
     console.error('Error deleting account:', error);
     return NextResponse.json(