fix(client/android): ensure VpnTunnelService calls startForeground on all auto-start paths

[sentry]

This change addresses ForegroundServiceDidNotStartInTimeException on Android 12+ devices, which occurred when the VpnTunnelService was started via startForegroundService() but failed to call startForeground() within 5 seconds.

The root cause was that the startLastSuccessfulTunnel() method, invoked during auto-connect scenarios (e.g., boot, always-on VPN), had early-exit paths (no saved tunnel, VPN permission not granted, or configuration parsing errors) that returned or stopped the service without first calling startForegroundWithNotification().

The fix involves:

1. Moving the call to startForegroundWithNotification() to the very beginning of startLastSuccessfulTunnel(), ensuring it is always executed within the required timeframe, regardless of subsequent logic.
2. Extracting the common cleanup logic for failed auto-connect attempts into a new private method, abortAutoConnect(). This method now handles setting the tunnel status to disconnected, updating the Quick Settings tile, explicitly calling stopForeground(true) to dismiss the notification, and finally stopSelf().
3. All early-exit paths in startLastSuccessfulTunnel() now call abortAutoConnect() to ensure a consistent and clean shutdown, including proper notification dismissal, even if the service remains bound.

This prevents crashes related to the foreground service lifecycle and ensures the UI (specifically the persistent notification) accurately reflects the VPN's disconnected state when auto-connect fails.

Fixes OUTLINE-CLIENTS-NDYK6

_{@sentry <feedback>: Autofix iterates on these changes
@sentry stop iterating: Autofix stops iterating on this run}

_{This PR was automatically generated by Sentry at no cost. You can adjust this setting at any time.}

[greptile-apps]

Confidence Score: 5/5

[Medium impact] This PR appears safe to merge; the failed auto-connect paths now remove the foreground notification.

Summary

This PR starts the Android foreground notification before auto-connect can return early.

• Failed attempts now share abortAutoConnect(), which marks the tunnel disconnected, refreshes the tile, removes the notification, and stops the service.
• The previous notification finding is fully addressed. No new actionable issues were found.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Auto-connect request] --> B[Load saved tunnel]
  B --> C[Start foreground notification]
  C --> D{Saved tunnel and VPN permission?}
  D -->|No| F[abortAutoConnect]
  D -->|Yes| E[Read configuration and start tunnel]
  E -->|Exception| F
  E -->|Success| G[VPN connected]
  F --> H[Mark disconnected and refresh tile]
  H --> I[Remove notification]
  I --> J[Stop service]

Loading

_{Reviews (2) · Last reviewed commit: "fix(client/android): ensure foreground s..." · Reviewed by Greptile}

[fortuna]

This doesn't look like a good design. disconnecting the tunnel, updating the tile, stopping the foreground notification and stopself all feel part of the same lifecycle transition. We shouldn't have to repeat this sequence everywhere.

At a minimum we need perhaps a disconnect method that does all those actions. But it perhaps needs a deeper look into the apis to simplify and cleanup