Fusion - the Fusion 360 Bridge

@@ -97,6 +97,21 @@ Three distinct states that look identical to a naive caller, all now distinguish Collapsing these into one error is what sent ab hunting a phantom dialog (#38) and made a 9-minute surface look like a dead add-in (#40). +### A kill needs KILL-GRADE evidence (learned 2026-08-21, three dead Fusions in one day)++`IsHungAppWindow` alone can NEVER authorize a force-restart. A heavy main-thread modeling+script (STEP import, saveAs) starves the add-in's HTTP thread via the GIL, so the 3s status+probe and the 5s health probe BOTH time out, and the host window legitimately stops pumping+messages - a working Fusion is indistinguishable from a hung one in a single snapshot. The+old gate taskkilled three healthy Fusions mid-work; the logs just stop mid-write, no crash+report, and the pattern reads as "something external keeps closing Fusion".++`_confirmed_hung()` (server.py) is the only path allowed to precede `kill`: hung NOW, plus a+refused 20-SECOND status probe (a merely starved add-in answers intermittently within that),+plus 180s+ of persistence since first observed. Anything less returns `fusion_addin_busy`+with "WAIT, do not restart". Same law as the busy guard from #41: a remediation that+destroys state needs a stronger signal than the absence of a fast answer.+ ## The deterministic-close rule (John, 2026-08-21, after the THIRD Save dialog)  > "save programmatically before a dialog pops up asking you to save. cuz that will make all