docx/pptx editors still open the main part by name

[Mearman]

The readers now resolve the main part from the root officeDocument relationship (#1314), but the edit path still opens it by name. packages/documents.js/src/edit/docx/editor.ts has its own DOCUMENT_PART_PATH = "word/document.xml" and throws package has no root element at word/document.xml; packages/documents.js/src/edit/pptx/editor.ts does the same with PRESENTATION_PART_PATH from edit/pptx/scaffold.ts.

So openDocx/openPptx on the exact file #1314 was about (body at word/document2.xml, which Word opens fine) throws, even though readDocxContent on the same package now reads it.

The docx side looks like resolving once in openDocx and threading the resolved path through the editor's media config and addRelationship call sites. The pptx side is more tangled: PRESENTATION_PART_PATH is a scaffold export that the writer genuinely needs as a literal when it builds a new package, so the read-an-existing-package path needs separating from the build-a-new-one path rather than just swapping the constant.

ooxml.js's findMainPartPath is the resolver, already exported.

[Mearman]

Fixed in #1347, released as documents.js@7.20.33.

Verified against the published package, in a scratch directory with npm i documents.js@7.20.33: openDocx on a docx whose body is at word/document2.xml opens it, appending a paragraph and re-encoding puts the change in word/document2.xml with word/document.xml still absent, and reopening the written bytes shows both paragraphs. openPptx on a deck whose presentation is at ppt/presentation2.xml opens it and addSlide takes it from one slide to two. On documents.js@7.20.32 the same script throws package has no root element at word/document.xml and package has no root element at ppt/presentation.xml.

Both editors resolve the main part once at open time through findMainPartPath and use it for every read, relationship and write. The read-versus-build split you asked for turned out to be the substance of it rather than a tidy-up: createEmptyDocxPackage/createEmptyPptxPackage are choosing the part name, so they keep writing the conventional literal, and PRESENTATION_PART_PATH stays exported from the scaffold for them. The editors get their own edit/docx/parts.ts and edit/pptx/parts.ts instead.

Directories for new parts are derived from wherever the resolved main part sits, so a conventional package still gets word/media and ppt/slides exactly as before, while a package whose main part is elsewhere keeps its new parts beside it. SlideContext carries the presentation part path, because removing a slide means resolving that exact part's relationships to find the p:sldId entry pointing at the slide rather than looking at the slide's own.

Ten tests, each verified to fail with the resolution reverted, on fixtures carrying the identical document and deck the conventional fixtures do so the assertions are the conventional behaviour rather than something weaker.