docx: comment.py creates duplicate comments relationships when existing part uses another filename

Summary

comment.py assumes that the existing comments part is word/comments.xml. A document with its comments relationship correctly targeting word/comments2.xml gets a second comments relationship and duplicate comment ID 0 when a comment is added. The command reports success, but python-docx can no longer access the output's comments.

Tested at dbd4588f9e1033efb41dad4bef2f7947c8993d44 using Python 3.12.14 and python-docx 1.2.0.

Reproduction

1. Use python-docx to create a document with a paragraph and a comment (ID 0), then save it as original.docx.
2. In the ZIP package, rename word/comments.xml to word/comments2.xml. Update its Target in word/_rels/document.xml.rels and its PartName in [Content_Types].xml accordingly. Save as renamed.docx.
3. Verify Document("renamed.docx").comments loads the existing comment successfully.
4. From the repository root run:

python -X utf8 skills/docx/scripts/comment.py renamed.docx "New comment" -o commented.docx

5. Inspect the output ZIP and access Document("commented.docx").comments.

Actual result

The command exits 0 and reports "Added comment id=0". The output has both comments.xml and comments2.xml, two main-document relationships with the comments relationship type, and comment ID 0 in both parts. Accessing its comments through python-docx raises:

ValueError: multiple relationships of type 'http://schemas.openxmlformats.org/officeDocument/2006/relationships/comments' in collection

Control: with the original standard filename, the helper assigns ID 1, leaves one comments relationship, and the output contains comment IDs 0 and 1.

Expected result

Resolve the existing comments part through the document's relationship type, preserve it, and allocate the new ID from that part. A valid alternative target filename should not create a duplicate comments relationship.

Cause and suggested correction

comment.py hardcodes word/comments.xml and allocates IDs from that path. _ensure_comment_relationships checks for the expected target instead of resolving the existing comments relationship.

Reuse the relationship's resolved part and validate relationship cardinality before writing output. Add a renamed-part regression and retain the standard-name control.

Scope and related reports

The renamed input loaded successfully before the operation. The demonstrated result is package inconsistency and an independent reader failure; native Word repair/rendering was not tested.

This differs from #1770/#1790 (missing relationship file) and #1821/#1824 (missing namespaces). The inspected #1824 patch does not address target resolution. Targeted public issue/PR review found no matching report.