Local server stops after swipe-away until app is reopened

## Problem

On a OnePlus 7 / Android 12 running v0.14.0b2, the local server at `localhost:5600` stops exposing newly recorded Android activity after the app is removed from recents. Reopening the app starts the server and backfills the missing interval from Android `UsageStats`, so the data was available to import but was not persisted or queryable while the app process was down.

The source report also mentions **force-stop**. Android deliberately prevents all app components, alarms, and sticky-service restarts after a force-stop until the user launches the app again; that case cannot provide an always-live local API. Swipe-away is distinct and should be investigated separately.

Source report: #247

## Current implementation

In v0.14.0b2 and current `master`:

- `BackgroundService` is a foreground service and returns `START_STICKY`.
- The manifest leaves `android:stopWithTask` at its default (`false`).
- The activity starts the service and schedules hourly event parsing.
- There is no `onTaskRemoved` instrumentation or explicit restart fallback, so the report does not yet tell us whether OxygenOS destroys the service, suppresses the sticky restart, or only stops the native server.

## Scope

- Reproduce **swipe-away** separately from force-stop on Android 12 / OxygenOS.
- Capture `BackgroundService` lifecycle and process-exit evidence around removal from recents.
- Keep the local server/API available after a normal swipe-away, or restart it automatically when Android permits.
- Document the unavoidable force-stop boundary rather than presenting it as recoverable.

## Acceptance criteria

- [ ] Swiping ActivityWatch away from recents does not permanently stop `localhost:5600`; if the process is killed, service/server recovery is verified without reopening the activity.
- [ ] Activity events recorded after swipe-away become queryable without reopening the app.
- [ ] The behavior is tested on Android 12, with OnePlus/OxygenOS battery-management behavior recorded.
- [ ] Force-stop behavior is documented as an Android platform limitation.
- [ ] Any restart fallback avoids a tight crash/restart loop and follows Android foreground-service restrictions.

## Diagnostic request

For an affected device, capture the persistent-notification state and filtered logs while reproducing **swipe-away only**:

```shell
adb logcat -c
adb logcat -v time BackgroundService:I RustInterface:I ActivityManager:I AndroidRuntime:E '*:S'
```

The key distinction is whether `BackgroundService destroyed` appears, whether the process exits, and whether `BackgroundService created` / `Starting server...` follows without opening the activity.