Stripe: Kundendaten, Rechnungsnummer, manueller Zahlungseingang

Rueckmeldung der Buchhaltung und des Stripe-Calls (dev/2026-08-26-stripe/):
Stripe kannte bisher nur die E-Mail des Kunden, Zahlungen waren im Dashboard
weder ueber die Bestell- noch ueber die Rechnungsnummer auffindbar, und ein
Zahlungseingang mit falschem Verwendungszweck zwang die Buchhaltung dazu, die
Rechnung von Hand zu schreiben.

- SE1: Der Checkout haengt einen Stripe-Customer mit Name, E-Mail und
  Rechnungsanschrift an die Session (customer statt customer_email); die ID
  liegt an shopping_users und wird wiederverwendet. Namensformat "Vorname
  Nachname (Firma)", reine Firmenkunden unter der Firma. Faellt die
  Customer-Anlage aus, laeuft der Checkout auf dem bisherigen Weg weiter.
  DSGVO-Loeschungen entfernen jetzt auch das Customer-Objekt; die Charges
  bleiben als Buchungsbeleg bestehen.
- SE2: StripeMetadataBuilder als einzige Quelle fuer Metadaten und die
  description (Bestellnummer, Referenz, Kundenname) - damit greift die
  Dashboard-Suche, die bisher nichts Lesbares zu fassen bekam.
- SE3: Die Rechnungsnummer entsteht erst nach der Zahlung und wird daher per
  Job am PaymentIntent nachgetragen (Vorab-Reservierung wuerde Luecken im
  Nummernkreis erzeugen). stripe:backfill-invoice-metadata traegt sie
  rueckwirkend ab dem Go-Live 2026-07-10 nach.
- SE4: Neuer Admin-Button "Zahlungseingang erfassen" an jeder unbezahlten
  Bestellung - bisher gab es ihn nur bei Rechnungskauf, und er setzte nur
  paid, ohne Rechnung, Punkte, Abo-Aktivierung oder Mail. Der neue Weg laeuft
  durch paymentStatusPaidAction, verlangt den Verwendungszweck als Beleg und
  laesst einen abweichenden Betrag nur mit ausdruecklicher Bestaetigung zu.
- S6.4 (aus dem Juli-Plan vorgezogen): stripe:sync-payment-status gleicht
  offene Zahlungen aktiv gegen die API ab. Aufgefallen beim Testlauf - ein nie
  zugestellter Webhook war bisher nicht reparierbar, das Geld lag bei Stripe
  waehrend die Bestellung auf offen stand. Laeuft stuendlich im Scheduler.
- 110 Tests (Pest) fuer alle Pfade, Stripe-Client durchgehend gemockt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

app/Jobs/SyncStripeInvoiceReference.php

@@ -0,0 +1,48 @@
+<?php
+
+namespace App\Jobs;
+
+use App\Models\ShoppingPayment;
+use App\Models\UserInvoice;
+use App\Services\Payment\Stripe\StripeInvoiceReferenceService;
+use Illuminate\Bus\Queueable as BusQueueable;
+use Illuminate\Contracts\Queue\ShouldQueue;
+use Illuminate\Foundation\Bus\Dispatchable;
+use Illuminate\Queue\InteractsWithQueue;
+use Illuminate\Queue\SerializesModels;
+use Illuminate\Support\Facades\Log;
+
+/**
+ * Trägt die MIVITA-Rechnungsnummer am Stripe-PaymentIntent nach
+ * (Plan dev/2026-08-26-stripe/, Phase SE3).
+ *
+ * Asynchron, weil der Auslöser im Webhook-Paid-Pfad sitzt: ein API-Call zu
+ * Stripe darf die Antwortzeit des Webhooks nicht belasten und erst recht
+ * nicht dazu führen, dass Stripe den Webhook als fehlgeschlagen wertet.
+ */
+class SyncStripeInvoiceReference implements ShouldQueue
+{
+    use BusQueueable, Dispatchable, InteractsWithQueue, SerializesModels;
+
+    public $tries = 3;
+
+    public $timeout = 30;
+
+    public function __construct(
+        public ShoppingPayment $shoppingPayment,
+        public UserInvoice $userInvoice,
+    ) {}
+
+    public function handle(StripeInvoiceReferenceService $service): void
+    {
+        $service->sync($this->shoppingPayment, $this->userInvoice);
+    }
+
+    public function failed(\Throwable $e): void
+    {
+        Log::channel('stripe')->error('Rechnungsnummer konnte nicht an Stripe übertragen werden: '.$e->getMessage(), [
+            'shopping_payment_id' => $this->shoppingPayment->id,
+            'user_invoice_id' => $this->userInvoice->id,
+        ]);
+    }
+}