fix: Bestell- und Abrechnungsprozess vor Go-Live abdichten

Fuenf Luecken zwischen Checkout, Zahlung und Stornierung geschlossen.

1. Bestellung ohne Stripe-Sitzung blieb dauerhaft haengen
   Schlug stripe.checkout.sessions.create fehl, blieb die Bestellung auf
   "NEU" ohne stripeCheckoutSessionId stehen. Damit griff kein einziger
   Aufraeumweg: der Abbruch-Klick braucht die Sitzungs-ID, der CronJob
   filterte solche Bestellungen sogar aktiv heraus, und ein Stripe-Event
   kann es ohne Sitzung nicht geben. Der reservierte Lagerbestand blieb
   fuer immer blockiert, und die Oberflaeche schickte die Kundschaft dabei
   auf die Erfolgsseite ("wir melden uns") — obwohl es keinen Weg gab,
   diese Bestellung je zu bezahlen.

   Die Route loest die Bestellung jetzt selbst auf (Bestand zurueck,
   Status STORNIERT mit Notiz) und antwortet mit einem ehrlichen Fehler,
   der ausdruecklich sagt, dass nichts abgebucht wurde. Laesst sich die
   Sitzungs-ID nicht speichern, wird die Sitzung sofort wieder
   geschlossen und derselbe Weg gegangen — eine "NEU"-Bestellung ohne
   Sitzungs-ID kann so nicht mehr entstehen. Der CronJob raeumt
   Altbestaende trotzdem ab (Filter entfernt).

2. Kaufabbrueche standen als Bestellungen im Kundenkonto
   getOrdersForCustomer lieferte auch den Status "NEU" aus. Ein gerade
   abgebrochener Kauf stand damit bis zu 45 Minuten lang mit
   Bestellnummer und Summe in der Liste und sah aus wie ein zustande
   gekommener Kauf. "NEU" wird dort jetzt ausgeblendet; in der
   Bestellverfolgung bleibt die Bestellung auffindbar, heisst aber
   "Zahlung ausstehend" statt "Neu".

3. Admin-Storno einer bezahlten Bestellung erstattete kein Geld
   Status wurde gesetzt, Ware zurueckgebucht, der Betrag blieb beim Shop.
   Der Storno erstattet jetzt ueber die Stripe Refunds API und setzt
   Payment.status auf REFUNDED.

4. Admin-Storno schloss die offene Stripe-Sitzung nicht
   Die Kundschaft konnte danach noch bezahlen; der Webhook fand die
   Bestellung nicht mehr auf "NEU" und brach still ab. Die Sitzung wird
   jetzt geschlossen, und der Webhook protokolliert eine Zahlung auf eine
   nicht mehr offene Bestellung laut, statt sie zu verschweigen.

5. Erstattungen und Rueckbuchungen kamen im Shop nicht an
   charge.refunded und charge.dispute.created werden jetzt verarbeitet:
   eine volle Erstattung aus dem Dashboard setzt Payment auf REFUNDED,
   eine Teilerstattung wird protokolliert, eine Rueckbuchung landet als
   Vermerk an der Bestellung. preflight prueft beide Abonnements mit.

Scheitert ein Stripe-Aufruf beim Storno, wird die Stornierung nicht
zurueckgenommen — der offene Punkt erscheint als Fehlermeldung im
Admin-Bereich und als order.cancel_incomplete im Audit-Log.

tsc: 0 Fehler. vitest: 294/294 gruen (ein Regressionstest fuer den
502-Fall neu). eslint: sauber.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

src/lib/account-data.ts

@@ -10,9 +10,30 @@ export type OrderWithDetails = Order & {
   returnRequest: ReturnRequest | null;
 };
 
+/**
+ * Bestellungen eines Kontos — OHNE die noch unbezahlten.
+ *
+ * Eine Bestellung entsteht bereits beim Start des Checkouts und steht bis zur
+ * bestaetigten Zahlung auf "NEU". Die allermeisten dieser Datensaetze sind
+ * keine Bestellungen, sondern abgebrochene Kaufversuche: geschlossener Tab,
+ * Zurueck-Knopf, weggelegtes Handy. Sie verschwinden von selbst wieder (siehe
+ * lib/order-release.ts), aber bis dahin vergehen je nach Weg bis zu 45
+ * Minuten.
+ *
+ * In dieser Zeit standen sie hier wie vollwertige Bestellungen in der Liste —
+ * mit Bestellnummer, Summe und Statuskennzeichen. Wer den Kauf gerade
+ * abgebrochen hatte, fand ihn also im Konto trotzdem als Bestellung wieder
+ * und musste annehmen, dass doch etwas zustande gekommen ist.
+ *
+ * Bezahlte Bestellungen sind davon nicht betroffen: der Webhook setzt sie
+ * binnen Sekunden auf "BEZAHLT", danach erscheinen sie hier wie gewohnt.
+ * "STORNIERT" bleibt bewusst sichtbar — dort gab es einen Vorgang, den die
+ * Kundschaft nachvollziehen koennen muss (fehlgeschlagener Einzug, Storno
+ * durch die Imkerei).
+ */
 export async function getOrdersForCustomer(customerId: string): Promise<OrderWithDetails[]> {
   return prisma.order.findMany({
-    where: { customerId },
+    where: { customerId, status: { not: "NEU" } },
     include: {
       items: { include: { product: { select: { slug: true } } } },
       shipment: true,