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.
 

docs/saas-umstrukturierungsplan.md

@@ -83,9 +83,10 @@ Empfohlene Routen:
 - `/`: Landingpage.
 - `/preise` oder spaeter `/pricing`: optional, falls Tarife eingefuehrt werden.
 - `/faq`: oeffentliche FAQ oder FAQ-Auszug.
-- `/registrieren`: Kundenregistrierung.
-- `/login`: Login.
-- `/passwort-vergessen`: Passwort-Reset.
+- `/registrieren` beziehungsweise aktuell `register.php`: Kundenregistrierung.
+- `/login` beziehungsweise aktuell `login.php`: Login.
+- `/passwort-vergessen` beziehungsweise aktuell `passwort-vergessen.php`:
+  Passwort-Reset.
 
 Landingpage-Inhalte:
 
@@ -121,6 +122,25 @@ Die App sollte eine Sidebar behalten, aber besser gruppiert werden:
 - Erfassung: Striche, Einzahlungen.
 - Auswertung: Kaffeeliste, Buchungen, Export.
 - Administration: Mitglieder, Hinweise, Einstellungen, Importe.
+- Konto: Kundenkonto und Logout. Public-Links wie Login und Registrierung
+  gehoeren nicht in die App-Sidebar.
+
+### Webspace- und Host-Strategie
+
+Empfohlen fuer den Start:
+
+- `kaffeeliste.de` oder `www.kaffeeliste.de` fuer Landingpage, Registrierung
+  und Login.
+- `app.kaffeeliste.de` fuer die geschuetzte App.
+- Keine Wildcard-Subdomains fuer Kunden.
+- Mandantenauswahl nach Login ueber Session und `tenant_memberships`.
+- Kundeneigene feste Domains oder Subdomains erst spaeter gezielt einrichten,
+  wenn DNS und Zertifikat pro Domain sauber geprueft sind.
+
+Damit bleibt der Betrieb webspace-tauglich: Fuer den Start reichen zwei feste
+Hosts mit normalen Let's-Encrypt-Zertifikaten. Die fachliche Tenant-Aufloesung
+ist in M3 vorbereitet; produktive Host-Rewrites, Cookie-Domain und Zertifikats-
+Details gehoeren zur M8-Betriebshaertung.
 
 ## Datenmodell
 
@@ -287,7 +307,7 @@ Uebersicht:
 | M4 | Datenmigration | Gestartet: Ledger-Tabelle, Legacy-Backfill, Paritaetscheck und Ledger-Service sind umgesetzt |
 | M5 | App-Kern | Dashboard, Striche, Einzahlungen, Mitglieder und Liste laufen |
 | M6 | Betriebsflows | Import, Export, Mail und Jahresprozesse sind auditierbar |
-| M7 | Landingpage | Erste werbliche Seite ist oeffentlich nutzbar; spaetere Ausbaustufen folgen |
+| M7 | Landingpage | Public-Seite und Auth-Seiten sind im gemeinsamen Stil nutzbar; spaetere Ausbaustufen folgen |
 | M8 | Haertung | Betrieb, Datenschutz, Monitoring und Isolation sind geprueft |
 | M9 | Cutover | Produktivumstellung ist vorbereitet und Legacy ist read-only |
 
@@ -427,6 +447,9 @@ Schritte:
 - Rollenpruefung zentralisieren: erster Owner/Admin-Check erledigt.
 - Erste Admin-/Owner-Seite fuer Grundeinstellungen: erledigt.
 - Erste Public-Landingpage mit CTA zu Login und Registrierung: erledigt.
+- Login, Registrierung, Passwort-Reset und E-Mail-Verifikation im Public-Stil:
+  erledigt.
+- App-Sidebar ohne Public-Login-/Registrierungslinks: erledigt.
 
 Ergebnis:
 
@@ -529,10 +552,13 @@ zu verwischen.
 Schritte:
 
 - Public-Layout mit bestehender Typografie und gruenem Akzent bauen. Erster
-  Stand als `landing.php` erledigt.
+  Stand als `landing.php` und `assets/css/public.css` erledigt.
 - Landingpage-Inhalte erstellen. Erster Stand erledigt.
 - Demo-Screenshot oder Demo-Ansicht einbinden.
 - CTA zu Registrierung und Login. Erledigt.
+- Login, Registrierung und Passwort-Reset in den Public-Stil integrieren.
+  Erledigt.
+- App-Sidebar von Public-Links trennen. Erledigt.
 - FAQ-Auszug strukturieren.
 - Keine App-Sidebar im Public-Bereich.