Engine cannot re-import its own exports: STEP fails, glTF fails until Zoo's own KITTYCAD_boundary_representation extension is stripped

[OneCrew01]

Context: API Makeathon participant (same account as #1291/#1292); found while building a preview pipeline over /ws/modeling/commands.

Behavior

Round-tripping a part through Zoo's own formats fails on re-import via import_files (websocket):

1. Zoo-exported AP242 STEP of a text-to-cad part → import_files → [{"error_code":"internal_engine","message":"import failed"}] — and sometimes no reply at all (>15 s silence on an otherwise healthy session).
2. Zoo-exported glTF of the same part → identical internal_engine failure.
3. The trigger for glTF is Zoo's own extension: stripping KITTYCAD_boundary_representation from the exported glTF (mesh untouched — lossless local edit) makes the identical file import perfectly. Repacking to GLB without stripping does not help.
4. Control cases: minimal hand-built OBJ and minimal glTF import fine (~50 ms), so import_files itself works — including as plain JSON text frames at ~450 KB.

Why it matters

Any export → re-import workflow (iterate on prior work, preview a stored part, remix someone's published file) breaks out of the box, using only Zoo-produced files. Workarounds we're shipping: strip the extension for glTF; for STEP, REST /file/conversion/step/obj (~1.3 s) then import the OBJ.

Repro

Rerunnable script (zero-dep Node) in our contest repo — happy to share directly or paste inline: build/export a part, then node server/spikes/ws-snapshot-spike.mjs --fmt step (fails verbatim) vs --fmt gltf-stripped (succeeds, renders via zoom_to_fit → take_snapshot).

Related small finding while in this area: bounding_box returns dimensions: {x:null, y:null, z:null} for imported objects (works for path-built solids) — happy to file separately if useful.