Migrate ZUGFeRD, PEPPOL BIS 3.0 DE, Factur-X FR and Peppol BIS 3.0 FR to the V2 draft import pipeline

[Groenbech96]

What & why

The German ZUGFeRD and PEPPOL BIS 3.0 DE formats and the French Factur-X FR and Peppol BIS 3.0 FR formats had not been migrated to the V2 (draft) inbound import pipeline - they only implemented the legacy V1 GetBasicInfoFromReceivedDocument / GetCompleteInfoFromReceivedDocument path. Customers using them could not use Read into Draft -> Prepare draft -> Finish draft, the independently reversible stages, or Copilot-assisted line and G/L account matching.

E-Document Core is not touched by this PR. Everything lives in the localization apps.

E-Document for Germany

• E-Document ZUGFeRD Handler implements IStructuredFormatReader (CII parsing) and IStructureReceivedEDocument / IStructuredDataType (lifting the embedded CII XML out of the ZUGFeRD PDF/A-3 container). It accepts either the PDF/A-3 file or plain CII XML.
• New enum extension values: "E-Doc. Read into Draft"::ZUGFeRD and "Structure Received E-Doc."::ZUGFeRD.
• E-Doc. PEPPOL BIS 3.0 DE Hdlr + "E-Doc. Read into Draft"::"PEPPOL BIS 3.0 DE", reusing the existing DE XRechnung UBL reader since both are CIUS of PEPPOL BIS Billing 3.0.
• The DE BuyerReference / Leitweg-ID handling that only existed in the V1 path is carried across into a DE table extension field "Buyer Reference DE" on E-Document Purchase Header, populated by both DE readers. The V2 draft pages are marked Extensible = false, so the value is stored but not surfaced in the UI yet.
• Selecting the ZUGFeRD or PEPPOL BIS 3.0 DE document format on an E-Document Service defaults Read into Draft Impl. accordingly.

E-Reporting FR

• E-Document Factur-X Handler - same CII + PDF/A-3 design as ZUGFeRD, with "E-Doc. Read into Draft"::"Factur-X FR" and "Structure Received E-Doc."::"Factur-X FR".
• E-Doc. Peppol BIS 3.0 FR Hdlr - UBL reader for invoices and credit notes with "E-Doc. Read into Draft"::"Peppol BIS 3.0 FR". The French party identifiers that InjectFrenchElements writes on export (SIRET in cac:PartyIdentification, cbc:EndpointID) are mapped back on import.
• Same document-format defaulting of Read into Draft Impl..

Linked work

AB#644275, AB#644276, AB#644277, AB#644278

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome

• E-Doc. DE Struct. Import Tests runs the real import pipeline for ZUGFeRD (invoice, credit memo, unsupported root element, re-run idempotency) and PEPPOL BIS 3.0 DE (invoice incl. Leitweg-ID), with new CII and UBL test resources.
• E-Doc. FR Struct. Import Tests covers Factur-X (invoice, credit memo, unsupported root element, re-run idempotency) and Peppol BIS 3.0 FR (invoice incl. SIRET mapping, unsupported root element) by calling the readers directly, so the FR test app needs no new dependencies on core internals.
• I could not compile or run the suite locally (no AL symbol packages in this environment), so please treat CI as the first full build/test signal.

Risk & compatibility

• No changes to E-Document Core, so no impact on plain PDF, PEPPOL XML, XRechnung or OIOUBL flows.
• Additive only: new codeunits, new enum extension values, and one DE table extension field. No obsoletions and no data upgrade.
• ZUGFeRD/Factur-X delivered as plain CII XML flow through Already Structured and the service Draft Format. When they arrive as a PDF/A-3 file, Structure Data Impl. has to point at the new localization structuring value; the readers also accept the PDF blob directly as a fallback.
• Transferring the DE buyer reference onto the created purchase invoice Your Reference is not included: V2 Finish Draft has no extension point for it today, and adding one would mean changing core.