Serve the app on app.qrmaster.net, marketing on www

Splits the two hostnames across one deployment. No files move: the Next app still
serves every route on both hosts, and the middleware decides per host which paths it
owns and 301s the rest. /login and /signup stay on www - all 82 marketing CTAs point
at /signup, which carries a hard canonical to www plus ad traffic.

src/lib/hosts.ts is the single source of truth for the boundary (APP_PATH_PREFIXES,
isAppPath, wwwUrl, appUrl, urlForPath). The middleware and every absolute-URL builder
read from it so they cannot drift apart.

- Split the overloaded NEXT_PUBLIC_APP_URL into a www and an app origin. It previously
  fed both public URLs and in-app URLs, so any single value was wrong somewhere. Most
  important: QRCodeCard encodes this origin into the QR code the user downloads and
  prints, so it must stay on www.
- Route Stripe return URLs, email links and OAuth redirects per path rather than
  against one origin, so /dashboard lands on app and /pricing on www.
- Cross the host boundary once, after a successful login: the router cannot push across
  origins, so that jump needs a full load. The user arrives signed in because the
  session cookie is scoped to COOKIE_DOMAIN.
- Keep the app host out of search indexes: X-Robots-Tag on every response plus a
  Disallow-all robots.txt via rewrite, and /sitemap.xml redirects to www.
- Point the TikTok callback fallback at www explicitly. It used to read
  NEXT_PUBLIC_APP_URL, whose meaning changed here, and only the apex domain is
  verified with TikTok.

Host splitting is inert while both origins are equal, so development is unaffected.

Verified: tsc clean, production build succeeds including the Edge middleware bundle,
and the path-to-host mapping is unit-checked (prefix traps like /created and
/settings-guide stay on www, query strings do not break matching).

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

PLAN_APP_SUBDOMAIN_2026-08-12.md

@@ -2,6 +2,22 @@
 
 Stand: 2026-08-12 · Ziel: die eingeloggte App liegt auf `app.qrmaster.net`, Marketing/SEO bleibt auf `www.qrmaster.net`.
 
+## Status
+
+| Schritt | Stand |
+|---|---|
+| B1 Cookie-Domain | committed + gepusht (`35ea8cc`) |
+| B2–B7 | Code fertig, typecheck + Production-Build grün, **noch nicht deployt** |
+| A4 Google Console | erledigt (beide Redirect-URIs eingetragen) |
+| A1 DNS, A2 Caddy, A3 .env, A6 Deploy | offen bei Timo |
+
+Deploy-Reihenfolge unverändert: B1 zuerst allein live und einen Tag beobachten, dann B2–B7.
+
+Neu gegenüber dem ursprünglichen Plan: `src/lib/hosts.ts` ist die einzige Quelle der Wahrheit
+für die Host-Grenze (`APP_PATH_PREFIXES`, `isAppPath`, `wwwUrl`, `appUrl`, `urlForPath`).
+Middleware, Stripe-Rückkehr-URLs und E-Mail-Links lesen alle daraus, damit sie nicht
+auseinanderdriften.
+
 ## Zielarchitektur
 
 **Ein Docker-Image, ein Container, zwei Hostnames.** Caddy routet `www.qrmaster.net` und
@@ -53,12 +69,23 @@ kein TLS-Fehler.
 ### A3. `.env` auf dem Server ergänzen
 Zwei Variablen statt einer. Die Trennung ist der Kern des ganzen Umbaus:
 
+Für **Deploy 1** reicht:
+
+```dotenv
+COOKIE_DOMAIN=.qrmaster.net
+```
+
+Für **Deploy 2** kommen dazu:
+
 ```dotenv
 NEXT_PUBLIC_WWW_URL=https://www.qrmaster.net
 NEXT_PUBLIC_APP_URL=https://app.qrmaster.net
-COOKIE_DOMAIN=.qrmaster.net
 ```
 
+`NEXT_PUBLIC_APP_URL` erst zu Deploy 2 umstellen - vorher zeigt es auf www und muss dort
+bleiben. Fehlen die Werte, greifen die Produktions-Fallbacks in `src/lib/hosts.ts`; ein
+localhost-Wert kann damit nicht in gedruckte QR-Codes gelangen.
+
 `NEXTAUTH_URL` bleibt `https://www.qrmaster.net` (wird nur noch von
 `api/social-assets/route.ts` gelesen, kein Auth-Bezug mehr).