Phase 9D: Tarif-Datenmodell, Cashier und hybride Rechnungskreise STR-/MAN-

Tarif-Datenmodell (Decision-Update):
- plans: Starter/Business/Pro/Agency mit Monats-/Jahrespreis (Jahres =
  10 x Monat), PM-Kontingent, Tageslimit, Stripe-IDs; idempotenter Seeder
- single_purchases: Einzel-PM, Extra-PM, Boost, PDF-Nachweis mit
  Status-Lifecycle und Stripe-Checkout-Referenzen
- laravel/cashier ^16.5 installiert (freigegeben); User ist Billable,
  Cashier-Migrationen published + ausgefuehrt; lokale invoices()-Relation
  ueberschreibt bewusst die Cashier-Methode

Hybride Rechnungskreise (Entscheidung 12.06.2026):
- invoice_number_sequences + InvoiceNumberGenerator: atomare fortlaufende
  Nummern pro Kreis (STR- fuer den neuen Stripe-Shop, MAN- fuer den
  manuellen Legacy-Kreis); Alt-Archiv legacy_invoices bleibt unveraendert
- ManualInvoiceService + billing:generate-manual-invoices (Scheduler
  taeglich 04:30): prueft aktive/grandfathered user_payment_options ohne
  Stripe-Subscription auf erreichtes Periodenende, friert die
  Rechnungsadresse als Snapshot ein, stellt die MAN-Rechnung aus
  (Zahlungsziel billing.manual_due_days) und schaltet die Periode weiter;
  Konditions-Overrides via legacy_conditions, sonst Netto-Preis +
  billing.vat_rate; nicht abrechenbare Faelle werden geloggt und
  beim naechsten Lauf erneut geprueft

Submit-Gate:
- User::hasActiveBooking() prueft jetzt echt (hinter
  billing.enforce_booking): Cashier-Abo, bezahlter Einzel-/Extra-PM-Kauf
  oder laufende Legacy-Vereinbarung (MAN-Kreis)

Suite: 468 passed, 4 skipped (17 neue Billing-Tests). Pint clean.
Offen fuer 9E: Stripe-Checkout/Webhooks, STR-Spiegelung, Slot-Logik auf
Plan-Kontingent, Migration der aktiven Legacy-Zahlungen in
user_payment_options.

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

app/Models/User.php

@@ -5,6 +5,7 @@ namespace App\Models;
 // use Illuminate\Contracts\Auth\MustVerifyEmail;
 use App\Enums\Portal;
 use App\Enums\RegistrationType;
+use App\Enums\UserPaymentOptionStatus;
 use Database\Factories\UserFactory;
 use Illuminate\Database\Eloquent\Factories\HasFactory;
 use Illuminate\Database\Eloquent\Relations\BelongsToMany;
@@ -14,6 +15,7 @@ use Illuminate\Database\Eloquent\SoftDeletes;
 use Illuminate\Foundation\Auth\User as Authenticatable;
 use Illuminate\Notifications\Notifiable;
 use Illuminate\Support\Str;
+use Laravel\Cashier\Billable;
 use Laravel\Fortify\TwoFactorAuthenticatable;
 use Laravel\Sanctum\HasApiTokens;
 use Spatie\Permission\Traits\HasRoles;
@@ -21,7 +23,7 @@ use Spatie\Permission\Traits\HasRoles;
 class User extends Authenticatable
 {
     /** @use HasFactory<UserFactory> */
-    use HasApiTokens, HasFactory, HasRoles, Notifiable, SoftDeletes, TwoFactorAuthenticatable;
+    use Billable, HasApiTokens, HasFactory, HasRoles, Notifiable, SoftDeletes, TwoFactorAuthenticatable;
 
     /**
      * The attributes that are mass assignable.
@@ -96,10 +98,11 @@ class User extends Authenticatable
      * Submit-Gate aus dem Decision-Update §5.1: Einreichen zur Prüfung
      * erfordert eine aktive Buchung.
      *
-     * Stub bis zum Tarif-Modul (Phase 9D/9E): solange
-     * `billing.enforce_booking` deaktiviert ist (Default), gilt jede:r als
-     * gebucht. Das Tarif-Modul ersetzt den Rumpf durch die echte
-     * Subscription-/Einzelkauf-Prüfung — die Schnittstelle bleibt stabil.
+     * Hybrides Modell: Eine Buchung ist entweder ein aktives Stripe-Abo
+     * (Cashier, STR-Kreis), ein bezahlter Einmalkauf (Einzel-PM/Extra-PM)
+     * oder eine laufende Legacy-Zahlungsvereinbarung (manueller MAN-Kreis).
+     * Solange `billing.enforce_booking` deaktiviert ist, bleibt das Gate
+     * offen (Launch-Schalter).
      */
     public function hasActiveBooking(): bool
     {
@@ -107,7 +110,20 @@ class User extends Authenticatable
             return true;
         }
 
-        return false;
+        if ($this->subscribed()) {
+            return true;
+        }
+
+        if ($this->singlePurchases()->grantingSubmission()->exists()) {
+            return true;
+        }
+
+        return $this->userPaymentOptions()
+            ->whereIn('status', [
+                UserPaymentOptionStatus::Active->value,
+                UserPaymentOptionStatus::Grandfathered->value,
+            ])
+            ->exists();
     }
 
     /**
@@ -169,6 +185,16 @@ class User extends Authenticatable
         return $this->hasMany(UserPaymentOption::class);
     }
 
+    public function singlePurchases(): HasMany
+    {
+        return $this->hasMany(SinglePurchase::class);
+    }
+
+    /**
+     * Lokale Rechnungen (STR- und MAN-Kreis). Überschreibt bewusst die
+     * gleichnamige Cashier-Methode — Stripe-Rechnungen werden beim
+     * Webhook-Sync (9E) in diese Tabelle gespiegelt.
+     */
     public function invoices(): HasMany
     {
         return $this->hasMany(Invoice::class);