Fix delayed state updates when stopping Clash services

[Goooler]

Overview

Fixes an issue where stopping Clash from the Home screen, Quick Settings tile, or external shortcuts can leave the app reporting a running or transitioning state for several seconds on some devices, including Motorola and Lenovo devices using aggressive background process management. The delayed stopped state also keeps settings that depend on clashRunning temporarily unavailable.

Root cause

The runtime had already closed the TUN interface and reset Clash, but the app did not clear StatusProvider.serviceRunning or broadcast ACTION_CLASH_STOPPED until Android invoked Service.onDestroy().

On the affected device, runtime cleanup completed in about 20 ms while onDestroy() arrived about 6.6 seconds after stopSelf(). Consumers therefore reflected Android service teardown latency rather than the actual Clash state.

Changes

• Add ClashServiceController to share lifecycle, status, notification, and broadcast handling between TunService and ClashService.
• Move runtime initialization into onStartCommand() so an existing service instance can handle a new start request.
• Track service start IDs and use stopSelf(startId) during shutdown.
• As soon as runtime cleanup finishes:
  • clear the active profile and running state;
  • broadcast ACTION_CLASH_STOPPED so state consumers update immediately;
  • remove the foreground notification;
  • request service shutdown.
• Keep onDestroy() handling as a fallback for service termination outside the normal runtime completion path.
• Remove the temporary trace logging used during diagnosis.

Validation

• Reproduced the original delay on a Motorola XT2603-1.
• Confirmed that the stopped state no longer waits for the delayed onDestroy() callback.
• Confirmed that a rapid stop/start sequence launches a new runtime, reloads the profile, and restores the foreground VPN service.