Fusion - the Fusion 360 Bridge

@@ -89,6 +89,23 @@ themselves with an on-screen caption first (see the fusion-driving skill's etiqu - Never "fix" a focus problem by foregrounding Fusion. Fix it by making the operation   work in the background - that is always possible with hwnd-targeted capture and UIA. +## The own-windows-only ruling (John, final, 2026-08-15 - via the kicad bridge)++The background contract got a cross-bridge design ruling: a bridge may only ever+manipulate ITS OWN app's windows. Never capture-restore-raise-demote any OTHER window,+and especially never a user's window - even "helpfully". This bridge's envelope is+compliant (it filters on the Fusion family pids), and it must STAY that way: any future+demotion/restore logic keeps the family-pid filter, no generic "whatever is foreground"+handling. The kicad bridge's guardian additionally uses WS_EX_NOACTIVATE + a+minimize-bounce (the OS returns focus naturally) - see the kicad-bridge-background+skill for that variant; worth considering here if the demote-to-bottom approach ever+proves insufficient.++Related rulings the same day: no terminal blips from shelled tools (the kicad repo's+quiet_console.py pattern: process-wide CREATE_NO_WINDOW + -NoProfile -NonInteractive ++explicit exit codes), and focus-requiring inputs hand the user's foreground BACK after+the input lands (shipped here in v1.9.16).+ ## The drain-sweep rule (v1.9.11, caught live 2026-08-15)  A modal dialog can pop AT the envelope's deadline and keep the foreground it grabbed