fix(runtime): keep live NE manager after wedged preference load

[cursor]

Bug and impact

When System Extension capture is already connected, a live apply can hit a wedged loadAllFromPreferences (nehelper never callbacks). #99 recovered by constructing a fresh NETransparentProxyManager and assigning it to self.manager.

stop() only drives the actor-owned manager. After that replacement, fallback teardown (HostBridge live-update failure → stop(dropWedgedConfiguration:) ) targets a disconnected preference and never calls stopVPNTunnel() on the running session. The old tunnel can keep capturing (failOpen: true leak) or leave NEDNSProxy intercepting after the SOCKS/DNS backend is gone (resolver blackhole).

Root cause

The wedged-enumeration recovery treated “create a new manager object” as equivalent to owning the live tunnel. Preference I/O and the in-memory session are not the same object after a timeout.

Fix

• If an owned manager already exists, keep it when enumeration times out or returns nothing.
• Only create a fresh manager when nothing is already owned (first enable / after reset).

Validation

• Reviewed configure → configureAndApplyRunning → HostBridge fallback stop() ownership.
• git diff --check
• Swift Network Extension build is not available in this Linux environment.