Fix embedded OLE object IDs in subdocuments

[aka-debug-jie]

Why

When several subdocuments contain embedded Excel objects, the generated DOCX
can retain all icons and packages while Word exposes only the first Worksheet
Object. Users see seven objects but cannot open six of them.

Root cause

SubdocComposer copied related parts without normalizing VML shape IDs, OLE
ObjectIDs, and paragraph anchor IDs that must be unique in the destination
document.

Change

• reserve identifiers already used by the destination and incoming subdocument
• renumber matching VML shape/@id and OLE ShapeID values together
• renumber OLE ObjectID and case-normalized w14:anchorId values
• preserve relationships, embedded payloads, APIs, and dependencies
• replace the regenerated first XLSX fixture with the exact public-attachment
  payload and bind all nine fixture mappings to the frozen attachment
• make the tracked CI launcher discover tests relative to itself, use
  sys.executable, propagate child failures, and emit a deterministic
  SHA-256 RUN/PASS ledger

Validation

• reproduced duplicate OLE identifiers on the unfixed baseline
• downloaded and froze the public attachment tar, then verified all nine mapped
  fixtures byte-for-byte; the corrected first workbook is 4,867 bytes with
  SHA-256 17ce75452390fd3057db51670b37df9c9027654a9589282d0834070ab6496cf9
• replayed all seven exact XLSX payloads and verified unique relationships,
  targets, VML/OLE IDs, ObjectIDs, anchors, valid OOXML packages, and sheets
  No.1 through No.7
• passed the destination-collision regression, related subdocument/embedding
  checks, repository-native suite, strict per-script suite, flake8,
  wheel/sdist builds, and archive audits in both review phases
• activated all seven objects in Windows Word/Excel 2024, saved and reopened
  the document, and confirmed all seven still map to No.1 through No.7

Scope and risks

This remains limited to body-level OLE objects using the sibling VML layout in
the reported attachment. It does not generalize arbitrary non-OLE VML ID
deduplication or OLE objects in headers, footers, or footnotes. The launcher
change ensures this PR's regressions are real CI-discovered tests; broader
nested-command cleanup remains separate. Remote GitHub Actions still require
repository-side approval to run.

Closes #621

[yangfan-yf-yf]

I reproduced #621 from the public attachment, and the identifier fix itself looks correct. On 9bbfc87b, the seven objects receive distinct paired v:shape/@id and OLE ShapeID values, distinct ObjectID values, and case-normalized unique w14:anchorId values. All seven relationships resolve to unique internal embeddings, and each XLSX passes ZIP, XML, and relationship checks. Existing body collisions, repeated renders, and the documented non-OLE and header/footer boundaries did not reveal another issue.

One fixture prevents me from approving the current head. tests/templates/issue_621_excel_0.xlsx is not the corresponding payload from the public attachment:

• attachment output/0.tmp_excel_0.xlsx, also stored as the first embedding in demo_doc_with_excel.docx: 4,867 bytes, SHA-256 17ce75452390fd3057db51670b37df9c9027654a9589282d0834070ab6496cf9
• committed fixture: 4,887 bytes, SHA-256 3b7d1befbe9fe6d4dfa8bee06b3dc424774b37079a884e89427c78577516805f

The workbook content is equivalent, but docProps/app.xml and docProps/core.xml differ, showing that this fixture was regenerated. The other six XLSX files and both DOCX templates are byte-identical to the attachment. This makes the “seven exact XLSX payloads” claim and the first expected hash inaccurate.

Please replace issue_621_excel_0.xlsx with the attachment’s exact payload and update its expected size and SHA-256. I did not find another blocker in the implementation.

[aka-debug-jie]

Thanks for tracing the first workbook back to the public attachment. The
follow-up commit replaces the regenerated fixture with the exact source member
and updates the expected size/hash:

• docx_demo_v2/output/0.tmp_excel_0.xlsx
• 4,867 bytes
• SHA-256 17ce75452390fd3057db51670b37df9c9027654a9589282d0834070ab6496cf9

I re-downloaded and froze the original attachment tar (125,534 bytes, SHA-256
e8dc9d28523d91407308585ae1396b5d039e936e94ac9ff1fec8ea7c375d6c78)
and verified all nine source-member-to-repository mappings byte-for-byte. The
public replay, destination-collision regression, related subdocument/embedding
checks, repository-native suite, strict suite, flake8, wheel/sdist builds, and
archive audits all pass. A Windows Word/Excel 2024 roundtrip also activates all
seven workbooks as No.1 through No.7 before and after saving.

No production OLE logic or other fixture changed in this follow-up.

[ahmetmusab42-stack]

I rechecked exact head abdd10c after the requested fixture correction. I downloaded the original #621 tar attachment again (125,534 bytes; SHA-256 e8dc9d28…5d6c78) and independently confirmed that issue_621_excel_0.xlsx is now byte-identical to the requested source member: 4,867 bytes, SHA-256 17ce7545…6cf9.

The public reproduction passes with seven distinct OLE/shape/ObjectID/anchor/relationship/embedding targets and sheets No.1 through No.7. The destination-collision, repeated-subdocument, and non-OLE VML boundary regressions also pass. I also ran Flake8 and built the sdist and wheel successfully.

I did not repeat the interactive Word/Excel activation roundtrip, so I am not claiming that GUI check, but I found no remaining blocker in the package/XML behavior or in the requested fixture correction. LGTM.