docProps core/app properties are read by name, not through their root relationships

[Mearman]

Same shape as #1314, one relationship over. packages/ooxml.js/src/typed/shared/metadata.ts reads docProps/core.xml and docProps/app.xml by name:

const CORE_PROPERTIES_PATH = "docProps/core.xml";
const APP_PROPERTIES_PATH = "docProps/app.xml";

OPC names both through root relationships (.../package/2006/relationships/metadata/core-properties and .../officeDocument/2006/relationships/extended-properties), so a package that puts its core properties somewhere else reads as having no metadata at all: readCoreProperties returns every field undefined, silently, for all three formats.

hasCoreProperties and patchCoreProperties in the same file have it too, and they matter more than the read: patchCoreProperties throws package has no 'docProps/core.xml' XML part to patch for a package that does have core properties under another name, and documents.js's setDocumentMetadata fast path gates on hasCoreProperties. All three need to resolve the same path or the gate and the patch disagree.

findMainPartPath in typed/opc.ts is the equivalent resolver for the main part; this wants the same treatment against the two metadata relationship types. Worth checking documents.js's own src/opc/core-properties.ts (addCoreProperties) at the same time, since it creates the part and declares the relationship.

I have not checked whether any real-world producer actually renames these, unlike #1314 where a client file did.

[Mearman]

Fixed in #1350, released as ooxml.js@9.1.1.

Verified against the published package: a package whose core properties sit at meta/core2.xml, named by the root core-properties relationship, now reads its title, answers hasCoreProperties true, and patches in place without creating a docProps/core.xml beside it. On ooxml.js@9.1.0 the same script reads undefined, answers false, and patchCoreProperties throws naming a part that package was never going to have.

You were right that the two gate functions matter more than the read, and that is what forced all three to move together rather than just readCoreProperties: hasCoreProperties answering false sends patchOoxmlCorePropertiesOnPackage down the build-from-scratch branch for a package that already has the part. They now share one resolver, so the gate, the patch and the read cannot disagree.

findRootRelatedPartPath generalises what findMainPartPath already did, and findMainPartPath is now that function applied to the officeDocument suffix. Both are exported. addCoreProperties in documents.js is unchanged: it creates the part, so it names it and declares the relationship, the same read-versus-build split the editors got in #1339.

Five of the seven new tests fail with the resolution reverted; the other two are the conventional-path fallback cases and pass either way, which is what they are for.

Still no real-world producer found that renames these, unlike #1314 where a client file did. The read side returning a silently empty metadata object rather than throwing is the part worth having fixed.