SD-2443 - fix: comments being merged by range when they shouldn't

[chittolinag]

Issue

• Imports without word/commentsExtended.xml get a range-based commentThreadingProfile. We passed that straight back into updateCommentsExtendedXml(), which returns null for range-based profiles, so our export dropped commentsExtended.xml entirely.
• Re-importing that DOCX makes importCommentData() fall back to detectThreadingFromNestedRanges(). In tables the ranges are naturally nested, so we stitched independent comments into one thread.

Proposed solution

1. Force commentsExtended.xml generation for any non–Google Docs export (pass 'word' to updateCommentsExtendedXml() when exportStrategy !== 'google-docs'), so we always stamp explicit w15:commentEx entries.
2. Add a regression test that exports a range-based profile, asserts the file exists, and verifies re-import keeps overlapping table comments separate.
3. (Optional) Cover detectThreadingFromRanges() with a unit test to ensure it skips when commentsExtended.xml is present.

[linear]

SD-2443 BUG: Nested Comments in Tables Combined on Re-Import

[github-actions]

Status: FAIL

The PR changes themselves are logic-only (the forceWordThreadingProfile override and the effectiveThreadingProfile computation) and don't introduce any new OOXML elements or attributes. No spec violations in the diff itself.

However, the changed file (commentsExporter.js) has a pre-existing attribute issue that's worth flagging since it's in scope:

---

w:email on w:comment — non-existent attribute

Per ECMA-376 §17.13.4.2, w:comment defines exactly four attributes: w:id (required), w:author, w:date, and w:initials. There is no w:email attribute in the schema. The attribute is written into the output XML at line 135 of updateCommentsXml and will be present in every exported word/comments.xml. Word will silently ignore it, but it makes the file non-conformant.

• File: commentsExporter.js:39 (set on the definition object) / commentsExporter.js:135 (preserved in the rebuilt attributes)

See https://ooxml.dev/spec?q=comment+content+wordprocessingml for the full attribute list.

---

Everything else checks out:

• w15:commentEx with w15:paraId, w15:paraIdParent, and w15:done — correct per the W15 extension schema
• w16cid:commentId and w16cex:commentExtensible — correct per their respective extension schemas
• w:id is always written as a string decimal, consistent with ST_DecimalNumber
• w:done on w:comment (line 43) is correctly stripped in updateCommentsXml and never reaches the output XML, so no issue there
• The custom:* namespace attributes are in a private namespace, which is conformant per the extensibility rules