[Extensibility Request][E-Document] Allow external IStructuredFormatReader implementations to populate Purchase Draft

Describe the issue

We are implementing support for importing Italian FatturaPA XML through the E-Document Core framework.
The public extensibility point for structured received documents appears to be IStructuredFormatReader, used through the extensible "E-Doc. Read into Draft" enum.
An external extension can therefore implement its own structured document reader. However, the standard Purchase Draft persistence used by Microsoft first-party implementations is not accessible externally.
The Microsoft implementations populate "E-Document Purchase Header" and "E-Document Purchase Line" and then persist/use that data through internal E-Document purchase-draft infrastructure.
These objects are currently internal, so an external IStructuredFormatReader implementation can parse the received document but cannot populate the standard E-Document Purchase Draft using the same supported path as first-party implementations.
This creates an extensibility gap for partner/localization apps that want to support additional structured document formats without recreating a parallel purchase-draft framework.

Expected behavior

An external implementation of IStructuredFormatReader should have a supported public API to populate and persist the standard E-Document Purchase Draft.

The expected flow is:

1. Structured received document
2. custom IStructuredFormatReader
3. standard E-Document Purchase Draft
4. standard vendor / line mapping
5. standard purchase-order matching / review

Purchase Invoice or Purchase Credit Memo
The requested change is to expose the minimum API required to achieve this.
Possible approaches could be:
expose the required purchase-draft staging records and persistence procedure for external use; or
provide a public purchase-draft writer/buffer API that hides the internal implementation.
The important requirement is that third-party structured-format readers can create the same standard Purchase Draft result as first-party readers without depending on internal objects.

Steps to reproduce

1. Create an extension that depends on E-Document Core.
2. Add a custom value to the extensible "E-Doc. Read into Draft" enum.
3. Implement IStructuredFormatReader for that enum value.
4. Parse a structured electronic document inside ReadIntoDraft(...).
5. Attempt to populate the standard E-Document Purchase Draft in the same way as the first-party structured-format implementations.
6. Observe that the required "E-Document Purchase Header", "E-Document Purchase Line" and related draft persistence infrastructure are internal and therefore unavailable to the external extension.

As a result, the external implementation cannot complete the standard Purchase Draft workflow even though IStructuredFormatReader itself is exposed as an extensibility point.

Additional context

Our concrete use case is importing Italian FatturaPA XML.
We would like to keep the complete process inside the standard E-Document lifecycle:

1. FatturaPA XML
2. E-Document Core
3. custom IStructuredFormatReader
4. standard E-Document Purchase Draft
5. standard mapping / review
6. Purchase Invoice / Credit Memo

The goal is specifically to avoid implementing and maintaining a separate custom purchase-draft framework when E-Document Core already provides the required standard workflow.
This extensibility would also benefit other partner or localization implementations of structured XML/EDI formats.
We are willing to contribute the required code change once the issue is approved.

Cross-reference: https://github.com/microsoft/ALAppExtensions/issues/30406

I will provide a fix for a bug

• I will provide a fix for a bug