Send a dedicated email for a switched Überweisung payment, not the full order-confirmation

New sendPaymentSwitchedEmail() — sent instead of sendOrderConfirmationEmail()
when confirmPaymentEmail.ts sees order.paymentSwitchedAt set. Resending the
full order-confirmation (with its invoice re-attached) after a payment-method
switch read like a brand-new purchase; this is a short, dedicated "Zahlung
erhalten" confirmation instead, matching the order-status-email shape.

Also bumps @einfach-produktiv/invoicing to 0.2.8, fixing a font-path bug
that broke every invoice PDF render inside the Payload backend specifically.

README.md

@@ -2097,6 +2097,25 @@ realistic today, but not meaningful states to switch *from* either).
   straight from `company-settings` fields rather than through the CMS
   richText renderer (which already links emails/URLs correctly).
 
+**New `sendPaymentSwitchedEmail()`** (`lib/orderEmail.ts`) — sent instead
+of `sendOrderConfirmationEmail()` when `confirmPaymentEmail.ts` sees
+`order.paymentSwitchedAt` set (a payment confirmation that came from
+switching an existing Überweisung order to Stripe, not a fresh gated
+checkout — see the Payload backend's own README on
+`switchPaymentToStripeEndpoint`). Same shape as the order-status emails
+(icon + admin-editable heading/bodyText + "Bestellung ansehen" button via
+`renderOrderStatusHtml`), no item table or invoice re-attachment — the
+invoice itself didn't change, only how it got paid, and the customer
+already received the full order-confirmation email once already. New
+`payment-method-switched` `EmailTemplateType`, added to
+`/email-preview`'s valid types too.
+
+**Bumped `@einfach-produktiv/invoicing` to 0.2.8** — fixes a font-path
+bug that broke every invoice/correction-invoice PDF render *inside the
+Payload backend* specifically (this frontend's own renders were
+unaffected). See that package's own README for the Turbopack
+asset-hashing root cause.
+
 ## Deployment
 
 - **Dockerfile**: 3-stage build (`deps` → `builder` → `runner`) with