writer fixed-slot collision with an unmanaged original relationship silently drops the fontTable relationship and leaves an orphan part

[kiki830621]

Problem

DocxWriter emits its own fontTable relationship at a fixed id (rId3). When the original word/_rels/document.xml.rels already uses that id for an unmanaged type (e.g. webSettings), pass 1 keeps the original rId3, and pass 2 does not append the typed fontTable relationship because emittedIds already contains rId3. The writer's fontTable relationship disappears, word/fontTable.xml stays in the package (still declared in [Content_Types].xml) as an orphan part — exit 0, no warning.

The 3.7.0 upgrade note says legal documents whose header/footer/image/hyperlink occupies rId1–rId4 are refused by name. That gate (slotCollisionIds) intersects the typed model's ids with the fixed slots; it never sees the original rels' ids, so this shape is not refused — it is lost.

Reproduction (verify R10, logic lens)

Real corpus file empty_field.docx (pandoc test suite), DocxWriter.write(_:to:) after one real edit (adding a header):

rId3 [webSettings] -> kept    rId2 [settings] -> kept    rId1 [styles] -> kept
rId6 [theme]       -> kept    rId5 [fontTable] -> GONE   rId4 [hyperlink] -> GONE

rId4 is a field-code HYPERLINK (instrText) the typed model does not claim, so the overlay drops it by its documented deletion semantics — that half is by design. rId5 (fontTable) is not: it is the fixed-slot collision above. 3/1025 corpus files reproduce it.

Scope / honesty

Present on main before PR #141 (merge was not changed by the cluster). 3.7.0's CHANGELOG states this limitation and points here.

Fix sketch

Include the original rels' ids in the slot-collision gate (refuse by name, like the typed-model case), or allocate the writer's fixed relationships around ids already present in the original rels.

Refs #139, #140. Surfaced by verify R10 of PR #141 (logic NEW-L10-2).