fix(datastore): commit stopwatch changes before acknowledging

[NikitaMGrimm]

Related: ActivityWatch/aw-android#70.

The stopwatch UI waits for the replace-event response, but the datastore can send it before SQLite commits. If Android kills the process before the next batch commit, the timer is still running when reopened.

Commit writes to general.stopwatch buckets before replying. Other buckets retain batching. The datastore test checks start, stop, and delete through a second SQLite connection immediately after each call.

Reproduced the stop/reopen case on an Android 16 emulator. All 28 datastore integration tests pass.

Before / after (two-second blank gap):

aw-stopwatch-before-after.mp4

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; no actionable issue was established.

Summary

The PR makes successful writes to general.stopwatch buckets commit before the datastore acknowledges them, while leaving other event writes batched. A new integration test checks that heartbeat, replacement, and deletion are immediately visible to another SQLite connection.

Diagram

sequenceDiagram
  participant Caller
  participant Worker
  participant SQLite
  Caller->>Worker: Stopwatch write
  Worker->>SQLite: Apply write in transaction
  Worker->>SQLite: Commit
  SQLite-->>Worker: Commit succeeds
  Worker-->>Caller: Acknowledge write

Loading

_{Reviews (1) · Last reviewed commit: "fix(datastore): commit stopwatch changes..."}

[TimeToBuildBob]

Verified at 3fa6fa1: applying only the new regression test to current master fails on the first independent SQLite read after heartbeat acknowledgement (QueryReturnedNoRows). At this head, cargo test -p aw-datastore passes: 17 unit tests plus 28 integration tests, 1 existing ignored test. The regression checks heartbeat/start, replacement/stop, and deletion through a second connection immediately after acknowledgement. Ordinary watcher batching remains unchanged by code inspection; this was not a separate behavioral test. Commit failures still return an error instead of successful acknowledgement. No blocking issue found; ready for maintainer review/merge. This verifies transaction visibility, not stronger power-loss guarantees than the existing SQLite settings.