SOLIDWORKS Bridge

@@ -347,7 +347,23 @@ not.  ## Roadmap -- v0.6.2 (this): **two one-liners that were not one-liners.** Pass 14 found the+- v0.6.3 (this): **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+  child, matched "terminable, not ours, not baseline, not the root" and latched+  `foreignChainSeen` on every ordinary launch. That is the `foreignChainSeen:true`+  seen live on 09-11, and it made sign-in recovery INERT: re-attribution bails on+  a foreign chain before it ever reaches the lineage proof. The chain is now+  recorded first and foreignness judged against the updated set plus every+  descendant of our own root. Three more things fell out of fixing it: a route+  ending `sldworksUpNotAttached` recorded no row at all, so the most important+  outcome for sign-in recovery had no evidence to point at; the log-authorship+  lineage proof is GONE, because "our launcher ran" is not the claim "this+  SOLIDWORKS came from it" (a user starting SOLIDWORKS from the Start Menu while+  our chain ran satisfied it); and re-attribution never checked that COM was+  actually attached, so it would relabel a session that was merely UP. 283 tests.+- v0.6.2: **two one-liners that were not one-liners.** Pass 14 found the   lineage proofs matching a bare pid NUMBER: Windows never validates a parent id,   and our launcher chain always exits once SOLIDWORKS is up — so a process whose   parent had merely REUSED that number would have satisfied the walk. Lineage now