Function export_step_json 

pub fn export_step_json(
    content: &[u8],
    schema: Option<String>,
    included: Option<Vec<u32>>,
    mutations_json: &str,
) -> Result<String, String>

Export STEP from raw bytes + a JSON mutation payload (the wasm bridge form of a MutablePropertyView diff).

Two payload shapes are accepted. A payload with a mutations array is the mutation LOG MutablePropertyView.exportMutations() writes (optionally with newEntities / georefMutations, see crate::MutationLog) and goes through crate::export_step_with_log, the writer that applies the whole mutation vocabulary with byte parity to the TypeScript StepExporter (#5941). Any other object is the older pre-serialized shape below. A payload carrying both is refused: which set of edits it meant is not recoverable.

The older mutations_json shape: { "attributeUpdates": [{expressId,index,value}], "propertyMutations": [{expressId,psetName,propName,value}] } where value is already STEP-serialized ('Name', IFCLABEL('x'), IFCREAL(1.)). An empty string means “no mutations” — a legitimate, common case (plain re-export). A non-empty string that fails to parse is a caller bug (a malformed payload, a version mismatch across the wasm boundary) and must not be treated the same way: silently falling back to “no mutations” would export a file that LOOKS like a successful re-export of the user’s edits but silently contains none of them. Callers get an Err instead, matching exportGlb’s and exportMerged’s fail-closed contract at this same wasm boundary.