Public-Auth-Seiten in Landingpage-Stil integrieren

- gemeinsames Public-CSS fuer Landingpage und Auth-Seiten ergaenzen
- Login, Registrierung und Passwort-/E-Mail-Seiten vom App-Layout trennen
- App-Sidebar von Public-Login- und Registrierungslinks bereinigen
- Webspace- und Subdomain-Strategie dokumentieren

docs/m3-saas-basis-vorbereitung.md

@@ -138,6 +138,7 @@ email-verifikation-senden.php
 email-verifizieren.php
 landing.php
 assets/images/landing-hero.png
+assets/css/public.css
 ```
 
 Umgesetzter Umfang:
@@ -153,8 +154,10 @@ Umgesetzter Umfang:
 - `konto.php` zeigt den aktuellen SaaS-Kontext fuer den angemeldeten User.
 - `functions.php` akzeptiert eine SaaS-Login-Session als erste Identitaetsquelle,
   laesst `DEV_AUTH_EMAIL` und `AUTH_USER` aber als Legacy-Fallback bestehen.
-- `footer.php` ist fuer nicht angemeldete Public-Seiten sicher und zeigt Links
-  zu Login und Registrierung.
+- `footer.php` bleibt App-Sidebar und zeigt keine Public-Login- oder
+  Registrierungslinks mehr.
+- Login, Registrierung, Passwort-Reset und E-Mail-Verifikation nutzen das
+  Public-Layout im Stil der Landingpage.
 - Passwort-Reset erzeugt Single-Use-Tokens und speichert nur Token-Hashes.
 - E-Mail-Verifikation erzeugt Single-Use-Tokens und setzt
   `users.email_verified_at`.
@@ -176,6 +179,7 @@ Umgesetzte Dateien:
 ```text
 landing.php
 assets/images/landing-hero.png
+assets/css/public.css
 ```
 
 Umgesetzter Umfang:
@@ -183,6 +187,8 @@ Umgesetzter Umfang:
 - Oeffentliche Landingpage ohne Legacy-DB-Zugriff.
 - Hero mit generiertem Bild-Asset, bestehender Typografie und gruenem Akzent.
 - CTA zu Login und Registrierung.
+- Login, Registrierung und oeffentliche Auth-Hilfsseiten sind optisch in den
+  Public-Bereich integriert.
 - Kurzabschnitt zu Stricherfassung, Mandantenfaehigkeit und Webspace-Betrieb.
 - Die geschuetzte App-Sidebar bleibt von der Public-Seite getrennt.
 
@@ -192,6 +198,8 @@ Entscheidung fuer den Webspace-Betrieb:
 
 - Keine Wildcard-Subdomains im ersten Schritt.
 - Primaere App-Adresse ist eine zentrale App-Domain wie `app.kaffeeliste.de`.
+- Die Public-Seite kann ueber `kaffeeliste.de` beziehungsweise
+  `www.kaffeeliste.de` laufen.
 - Der aktive Mandant wird nach Login ueber `tenant_memberships` und die PHP-
   Session gesetzt.
 - Bei genau einem Mandanten wird automatisch weitergeleitet.
@@ -202,6 +210,8 @@ Entscheidung fuer den Webspace-Betrieb:
 Noch offen:
 
 - `APP_PRIMARY_HOST` in der Zielumgebung setzen.
+- Optional `APP_PUBLIC_HOST` beziehungsweise Host-Rewrite fuer die Landingpage
+  in der Zielumgebung definieren.
 - Produktive Domain-/Zertifikatspruefung fuer einzelne feste Domains
   definieren.