Make sure multi-chain support works in patch_output_cif_files, which will require modifications to protenix structure processing

[k-chrispens]

The structure processing utilities for protenix currently assign a chain ID that may not match the reference CIF, which limits our evaluations downstream in the patching of the CIF. If we fix this upstream (possibly when bumping to protenix 1.0 or 2.0) we can undo the commenting out of the message in https://github.com/diff-use/sampleworks/pull/237/changes#diff-5c307432dbc6cd78fbf08459457c34a867551fd4314815dc1476f98ac8fb011eR163.

[marcuscollins]

@michael-diffuse Can you take a look at this one? It isn't trivial, but I'd like to consolidate the various things we have to do to fix our CIF outputs, and this is one of the big headaches. We probably need to come up with a design doc to catalog and start addressing all the issues in how structures are processed differently across the different models (RF3, Boltz, Protenix).

[michael-diffuse]

i work at a different diffuse 🙃

[manzuoni-astera]

Dug into this and wrote up the design doc you asked for — PR #303 (docs/design/cif-output-correctness.md), consolidating this with #68.

Root cause confirmed: Protenix's input JSON has no per-chain id slot (structure_processing.py:515,660), so the real chain IDs are dropped when the JSON is built and reinvented (A, B, C…) by SampleDictToFeatures (wrapper.py:393). RF3 and Boltz both preserve reference chain IDs; Protenix is the lone outlier. The real IDs are only set on the input-side array that gets discarded, so refined.cif carries the invented letters.

On re-enabling the commented-out return msg (patch_output_cif_files.py:159-168): it can't come back until the output chain IDs actually match the reference. Worse, with it disabled the patch zips chain keys by position (:157) — multi-chain residues can be remapped onto the wrong chain silently. That's flagged as the key hazard.

Discrete fix is only partial: single-chain / order-aligned multi-chain can be fixed now by relabeling from the reference via the existing AtomReconciler correspondence — but the reconciler keys on sorted chain position, not label, so general multi-chain (homo-multimers, L/H↔A/B, ligands) genuinely needs either the Protenix format bump you mentioned or a sequence/geometry chain-matcher we own. That's the design decision I'd want your call on (§7 of the doc).

[manzuoni-astera]

Tracking is now split across two existing PRs rather than opening a competing implementation:

• docs(cif): CIF output correctness design doc (#68, #238) #303 documents the cross-model chain/entity correctness design and the silent positional-chain remapping hazard.
• feat, fix(metada carrying): fix metadata dropping through the pipeline (atomworks, predictors), eliminate the post-fact patchign script. #301 contains the active implementation: sequence-based multi-entity matching, chain/numbering reconciliation, native entity-category carry, and retirement of the post-hoc patch script.

#301 currently has requested changes, so this P0 should remain open until that implementation (or an agreed replacement) lands on main.