Fix core properties namespace conflict

[JackSpiece]

Summary

Importing docxtpl also imports docxcompose when the subdocument extra is installed. docxcompose.utils changes the process-wide python-docx nsmap["cp"] entry to the custom-properties namespace. Later core-property assignments then append an element in that namespace instead of updating the existing core property.

This restores the standard core-properties mapping after the docxcompose imports. docxcompose keeps its own NS mapping, so its custom-property and subdocument behavior is unchanged.

The regression test renders a template, sets keywords, then inspects docProps/core.xml and verifies there is exactly one keyword element in the standard core-properties namespace.

Fixes #471

Verification

• All 37 repository test scripts pass individually
• Full flake8 target passes
• Source distribution and wheel build successfully
• Core-property, custom-property, and subdocument smoke tests pass with docxcompose 1.4.1 and 2.2.0

[yangfan-yf-yf]

I reviewed 45a11af against 1f143fb and reproduced #471 on the base: updating an existing keywords property leaves the original core-properties element and writes a second element in the custom-properties namespace. At this head, the same document contains exactly one cp:keywords element in http://schemas.openxmlformats.org/package/2006/metadata/core-properties with the updated value.

I also verified:

• all 37 repository test scripts pass when executed directly;
• the namespace behavior with docxcompose 1.4.1 and 2.2.0;
• custom properties still use the custom-properties namespace, with their package relationship and content type intact;
• subdocument and merge coverage passes;
• flake8 and sdist/wheel builds pass.

#658 touches separate logic in the same file, and the changes combine cleanly. I found no blocking issue.