DTH Character Studio v0.89.0

What's changed

• Running a character's visible ROM_… script by hand no longer saves the scene as rom-animations/<stem>_ROM.duf (runtime v103). That save is the DTH-Export flow's job — the hidden carriers still write it — but the manual script did it too, silently overwriting the flow-built ROM on disk and repointing the open scene's filename to the _ROM.duf. A manual run now builds the ROM on the timeline and stops. Run Tools → Refresh assets to regenerate installed scripts.
• A crashed Unreal editor no longer leaves the DTH Export button Working forever. The import's state is derived from files in the project's Saved/DTHStudio/ folder, so an editor that died mid-import — leaving a claimed job and a result frozen at running — kept re-deriving a live import on every poll, across app restarts, behind a deliberately inert button. The poll now measures liveness for a CLAIMED import: when no editor process exists at all, or every running editor is identified and none holds that project, the import is reported as the failure it is and the run ends through the normal outcome path (failure toast, files cleaned). The verdict abstains wherever the studio cannot actually see: an editor whose project can't be read might be the one running the import; a platform that cannot enumerate editors at all (everything off Windows, where the probe is a stub) decides nothing; a failed probe read is a read hiccup, not a dead editor; and a job still queued unclaimed is just waiting — that is the normal queue-then-open flow. A dead verdict also re-reads the result file before believing itself, so an import that finished in the moment the probe took is reported as the success it was.
• Every exporting DTH Export row now gets a FRESH Daz Studio session, and every row's export is judged by the exporter's own motion summary. Daz's re-evaluation of fitted followers silently degrades after a scene re-load inside one Daz session (measured 2026-08-24/25, DS4 4.24: every scripted export after a re-load froze eyes/grafts/clothing at 9–35% of the figure's moved frames, 5/5 reproductions — the exporter cannot fix it from inside). Two defenses ship together: - Fresh session per row (job-file contract v4, sessionPerRow; needs Runner v1.4.0): the Runner runs ONE row per Daz session and quits; the studio's new export supervisor starts the next session, kills a hung one (hard per-row timeout — a teardown was measured hanging indefinitely with the UI alive), requeues a crashed session's batch, and refuses to let a worn session (Daz already open with a scene) run row one. Older Runners keep working single-session — the gate below still catches the wear. - Motion-summary gate (studio-side, historical): after a batch, each scene's export log ("Alembic ROM motion summary", exporter ≥ 2.1.9) is parsed and the scene FAILS when multiple meshes moved on far fewer frames than the SAME meshes reached in earlier summaries of the same log — the measured degradation signature — or when nothing moved at all. Judging each mesh against its own history is what keeps scenes whose ROM legitimately leaves meshes still (a face the ROM never animates) from false-positiving; a first-ever export has no history and gates nothing. Thresholds are pinned by tests against verbatim blocks from both measured incident logs. A degraded scene drops out of the Houdini/Unreal continuation like any dead export set.