[client] Pull fresh TUN settings on Android rebuild instead of pushing state

The Android TUN rebuild consumed state pushed through notifications and
a Java-side snapshot, and both sources were unreliable. The DNS
search-domain notifier fired OnNetworkChanged with an empty string,
which the rebuild handler treated as the new route list, so any search
domain change rebuilt the TUN with zero routes and cut all tunnel
traffic. The rebuild also reused the search domains cached at the last
establish, so search domain updates never reached the TUN at runtime.

Make the notification a pure trigger and let the Java side pull a fresh
snapshot instead. Expose GetTunSettings on the Android SDK client: it
returns the current TUN route ranges, derived on demand by the route
manager from the client routes, the exit-node selection and the fake IP
blocks, together with the DNS search domains. The route notifier keeps
only its last-announced baseline to suppress triggers for unchanged
syncs; the TUN route state is owned by the route manager. SearchDomains
now locks the DNS server mutex since the pull arrives from a Java
thread.

Requires the matching android-client change that switches recreateTUN
to the pull API.

client/internal/engine_tunsettings.go

@@ -0,0 +1,20 @@
+package internal
+
+func (e *Engine) TunSettings() ([]string, []string) {
+	e.syncMsgMux.Lock()
+	routeManager := e.routeManager
+	dnsServer := e.dnsServer
+	e.syncMsgMux.Unlock()
+
+	var routes []string
+	if routeManager != nil {
+		routes = routeManager.CurrentRouteRange()
+	}
+
+	var searchDomains []string
+	if dnsServer != nil {
+		searchDomains = dnsServer.SearchDomains()
+	}
+
+	return routes, searchDomains
+}