Set Reply-To to sellerEmail, make From display name dynamic, fix stale footer docs

Customer replies to order-confirmation and resend-verification mail now
route to the seller's real address via Reply-To, and the From display
name reflects sellerName — but the From address itself stays
admin@mk360.de since sellerEmail's domain isn't confirmed SPF-authorized
on the Hostinger account yet (see the "SMTP From address pending SPF"
memory note for the follow-up). Also cleans up README references left
over from the previous footer rewrite (stale "company line" wording, a
dangling cross-reference to a renamed section).

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

README.md

@@ -114,7 +114,7 @@ explains what does have access instead.
 | `customers` | Storefront accounts — register/login/order-history, a second `auth: true` collection separate from the Payload admin's own `users` login | `customerNumber`, `firstName`/`lastName`/`email`, one default address, `cart` (server-side mirror), `emailVerified` (non-blocking). **Not public-read** — see "Orders & customer accounts" below |
 | `number-ranges` | Admin-configurable prefix + running counter for customer/order/invoice numbers — one row per tenant | `customerPrefix`/`customerNext`/`customerPadding`, `orderPrefix`/`orderNext`/`orderPadding`, `invoicePrefix`/`invoiceNext`/`invoicePadding`. **Admin-only**, no frontend read at all — internal to the two `beforeChange` hooks that assign these numbers |
 | `email-templates` | Editable subject/heading/body/footer for all 6 transactional emails this shop sends (see "Email templates & Live Preview" and "Status-change emails" below) | `type` (`order-confirmation`/`password-reset`/`order-shipped`/`order-cancelled`/`order-return-requested`/`order-returned`), `subject`, `heading`, `bodyText`, `footerText`. Public-read, has a Live Preview button |
-| `company-settings` | Structured business data for invoice PDFs *and* every email footer's company line (see "Invoice PDFs" below) — one row per tenant, own **Company** admin group (not Commerce — this is business identity, not a storefront concern) | `sellerName`/`sellerStreet`/`sellerZip`/`sellerCity`/`sellerCountry`/`sellerEmail`, `vatId`, `taxRatePercent` (admin-editable, not hardcoded), `bankDetails`. **Not public-read** — admin or `ORDER_SERVICE_SECRET`. Has a Live Preview button — see "Company Settings & Live Preview" below |
+| `company-settings` | Structured business data for invoice PDFs *and* every email's legal footer (Anbieterkennzeichnung, see "Invoice PDFs" below) — one row per tenant, own **Company** admin group (not Commerce — this is business identity, not a storefront concern) | `sellerName`/`sellerStreet`/`sellerZip`/`sellerCity`/`sellerCountry`/`sellerEmail`, `vatId`, `taxRatePercent` (admin-editable, not hardcoded), `bankDetails`. **Not public-read** — admin or `ORDER_SERVICE_SECRET`. Has a Live Preview button — see "Company Settings & Live Preview" below |
 
 All of the above except `company-settings`, `media`, `users`, `tenants`
 are grouped in the Payload admin sidebar under **Commerce** (`products`,
@@ -137,7 +137,7 @@ delivery-time disclosure (`shipping-settings`), order/customer/invoice
 numbering schemes (`number-ranges`), all 6 email wordings
 (`email-templates`, with Live Preview), and invoice seller data,
 bank details, and VAT rate (`company-settings` — also what every email's
-footer company line is sourced from). What still requires a code change:
+legal footer is sourced from). What still requires a code change:
 adding a new *field* to any collection (needs a migration), payment
 processing itself (not built), and anything structural in
 `orders`/`customers` beyond `status`/`returnReason` and the profile fields
@@ -348,7 +348,7 @@ inbox, not only in `/konto/bestellungen`.
   entrypoints every caller below goes through. `seller` (`company-settings`
   data) is passed in rather than fetched inside these functions, so a
   caller that also needs it for something else in the same request (e.g.
-  `orderEmail.ts`'s email footer, see "Configurable company data" below)
+  `orderEmail.ts`'s legal email footer, see "Legal footer (Anbieterkennzeichnung) on every email" below)
   fetches it once via `getSellerForInvoice()`, not twice.
 - **Original invoice — called from two places, same render function:**
   `app/lib/orderEmail.ts` (checkout attachment — a PDF-generation failure
@@ -654,15 +654,26 @@ mechanism as Posts/LegalPages/Testimonials (`useLivePreview()` from
   render functions, which call `buildLegalFooterLines()` themselves — one
   place composes the footer, not each call site. The Payload-side sends
   (password-reset, the 4 status-change emails, the *initial* verification
-  email) need the equivalent treatment via that repo's own
-  `src/lib/sellerInfo.ts`, not present in this checkout. Live Preview passes
-  `seller: null`, which falls back to `DEFAULT_LEGAL_FOOTER_LINES` (a
+  email) get the equivalent treatment via that repo's own
+  `src/lib/sellerInfo.ts`'s `buildLegalFooterLines()`/`getSellerFooterLines()`
+  — see that repo's README for its own copy of this section. Live Preview
+  passes `seller: null`, which falls back to `DEFAULT_LEGAL_FOOTER_LINES` (a
   placeholder Anbieterkennzeichnung) since there's no real order/tenant
   context there to fetch against. Note `company-settings` currently has no
   Handelsregister court/number or Geschäftsführer field — fine for a sole
   proprietorship, but would need adding if the business becomes a
   registered legal form (GmbH etc.), see that collection's own field list
   above.
+- **`From` display name is dynamic (`seller.sellerName`), the address
+  itself stays `admin@mk360.de`.** `Reply-To` is set to `seller.sellerEmail`
+  so a customer's reply actually reaches the seller regardless of the From
+  address. The address isn't also switched to `sellerEmail` because that
+  domain isn't confirmed SPF-authorized on the Hostinger account backing
+  `admin@mk360.de` yet — doing so without that confirmation risks
+  order-confirmation/verification mail landing in spam or bouncing outright.
+  Both `orderEmail.ts` and `alertAdmin.ts`'s `sendVerificationEmail` set
+  this the same way; `sendCriticalAlert` (internal, admin@mk360.de to
+  itself) doesn't need it.
 
 ### GDPR self-service