Phase 3: actual ZUGFeRD/Factur-X e-invoice generation

renderInvoiceEInvoice()/renderCorrectionInvoiceEInvoice() produce a
Factur-X-EN16931 hybrid PDF/A-3 (existing @react-pdf/renderer PDF +
embedded EN16931 XML) via @e-invoice-eu/core, instead of a plain PDF.
The plain renderInvoicePdf()/renderCorrectionInvoicePdf() stay unchanged
and are still what Live Preview uses — this only adds a post-processing
step for the actual send/download paths.

buildEInvoiceData()/buildCorrectionEInvoiceData() map InvoiceOrder/
CorrectionInvoiceOrder + InvoiceSeller into the library's raw UBL-shaped
Invoice object, reusing computeTaxBreakdown() for the tax math — one
implementation feeding both the human-readable and machine-readable side
of the same document. Verified end-to-end: rendered a sample invoice and
correction invoice, inflated the embedded XML stream out of the resulting
PDF/A-3 by hand (the library has no attachment-reading API to check
against), confirmed correct CrossIndustryInvoice XML, EN16931 guideline
reference, per-rate tax breakdown matching the order totals exactly, and
payment means with the IBAN from Phase 2 — not just "it didn't throw."

Found only through actually running it (not documented anywhere): every
EN16931 amount field requires a sibling `*@currencyID` key via the
library's runtime ajv validation, invisible in its TypeScript types.

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

package.json

@@ -12,8 +12,8 @@
     "lint": "eslint ."
   },
   "peerDependencies": {
-    "react": "^19.0.0",
-    "@react-pdf/renderer": "^4.0.0"
+    "@react-pdf/renderer": "^4.0.0",
+    "react": "^19.0.0"
   },
   "devDependencies": {
     "@react-pdf/renderer": "^4.5.1",
@@ -23,5 +23,8 @@
     "react": "^19.2.4",
     "typescript": "^5",
     "vitest": "^4.1.10"
+  },
+  "dependencies": {
+    "@e-invoice-eu/core": "^3.1.1"
   }
 }