aw-server 0.13.2 startup loop on corrupt SQLite DB; .recover restores data

## Environment

- ActivityWatch / `aw-server`: 0.13.2
- macOS 15.7.3 (24G419), arm64
- Storage backend: Peewee / SQLite

## Observed behavior

`aw-server` repeatedly exited during startup with:

```text
sqlite3.DatabaseError: database disk image is malformed
peewee.DatabaseError: database disk image is malformed
```

The bundled app's restart action produced the same startup failure. The database file was last modified on July 25, and the first retained log containing this error was July 27. I do not know what originally caused the corruption.

An independent read-only SQLite check reproduced it:

```text
$ sqlite3 -readonly peewee-sqlite.v2.db 'PRAGMA quick_check;'
Error: in prepare, database disk image is malformed (11)
```

There was no `-wal`, `-journal`, or backup file beside the database.

## Recovery result

After preserving the original file, the standard SQLite recovery path succeeded:

```sh
sqlite3 corrupt.db '.recover' | sqlite3 recovered.db
sqlite3 -readonly recovered.db 'PRAGMA integrity_check;'
# ok
```

Recovered data:

- 2 buckets
- 148,065 events
- Event range: 2026-01-30 through 2026-07-25
- 0 invalid event JSON rows
- 0 orphaned event rows

After replacing the corrupt database with the recovered one, the actual bundled `aw-server` started successfully. Both `/api/0/info` and `/api/0/buckets/` returned HTTP 200, and the full ActivityWatch app then launched normally.

## Suggested improvement

Could `aw-server` or `aw-qt` preserve the corrupt file and offer an automatic recovery/backup fallback (or at least show actionable recovery instructions) instead of remaining in a restart loop? This appears related to the older closed issue #271, but reproduces on 0.13.2 and the SQLite `.recover` path preserved the data successfully.