SOLIDWORKS Bridge

@@ -347,7 +347,23 @@ not.  ## Roadmap -- v0.6.3 (this): **the bridge called its own launcher a stranger.** Foreignness+- v0.6.4 (this): **the same mistake one route further down, and a window around+  lineage.** 0.6.3 stopped the bridge calling its ATTRIBUTED launcher foreign;+  pass 16 found it still doing so for the routes that cannot name what they+  started. `explorer` and `cmdStart` have no attribution root, so their root and+  descendant sets are empty and their own launcher processes matched every+  foreignness clause — on a machine whose only launcher processes were the ones+  the bridge had just started. Foreignness now needs POSITIVE evidence (a launcher+  that PREDATES our invoke); one that appeared after it, while a route that cannot+  name its root was running, is recorded as `possiblyOurs` — excluded from the+  foreign set and, as always, from the kill path, because "possibly ours" is a+  reason not to accuse and not to terminate alike. And lineage got the window it+  was missing: a dead parent is still acceptable (the launcher always exits), but+  it must have been SEEN ALIVE with that exact pid and creation time during the+  attempt, and the child must have been created inside that observed lifetime plus+  30s — otherwise a user's launcher that recycled our dead pid would have its+  SOLIDWORKS adopted as ours, with nothing alive left to contradict it. 285 tests.+- v0.6.3: **the bridge called its own launcher a stranger.** Foreignness   was judged BEFORE the chain was recorded in the same census pass, so on the   first census after an invoke the recorded chain was still empty and only the   attribution ROOT was excluded — our own `SWXDesktopLauncher`, the root's own