fix(google-health): keep long backfills out of reauth parking and settle overlapping sleep segments

A history backfill carried one access token through walks that outlive it.
After an hour every request answered 401, which classifies as a revoked
grant, so the account was parked at error_reauth with a refresh token that
was still valid, and every later run skipped it until a manual reconnect.
Running beside the hourly sync, the backfill also pushed the account over
Google's per-minute quota, and each 429 failed its whole collection.

- Walks take a token source that renews the access token before it expires
  and once more when Google refuses it mid-walk.
- A 429 is waited out (Retry-After, RetryInfo, else a doubling backoff) and
  the request repeated; it is never a reauth.
- error_reauth only short-circuits a run when the token endpoint refused the
  grant (needsReauth). A connection parked by a data request's 401 refreshes
  on its next run and clears itself when that run completes.
- One run per account at a time: syncs, the backfill and the sleep repair
  share an advisory lock. The hourly poll skips a held account, a manual
  sync answers 409 sync_in_progress, the backfill waits a bounded time.
- A backfill attempt records each collection it finishes cleanly
  (backfill_progress) and the next attempt resumes with the rest.
- The incremental watermark is stamped with the cycle's start, not its end.

Overlapping sleep segments that share a stage and an end share the natural
key (type, measuredAt, source, sleepStage). A re-score that moved one row
onto a sibling's slot threw P2002 and failed the sync on every run.

- A batch keeps one reading per natural key, chosen the same way each time
  (longer segment, then smaller externalId).
- A move that still collides is settled by reconcileExternalMeasurement,
  which retires the stale row, instead of failing the sync.
- Updates run before inserts, and the key-format rescue no longer re-keys a
  row this batch is moving.
- The sleep replace-by-window protects every session's fresh rows, so two
  overlapping sessions no longer tombstone and resurrect each other hourly.

Refs #1194, #1195

docs/integrations/google-health.md

@@ -120,6 +120,24 @@ GOOGLE_HEALTH_REDIRECT_URI="https://your-instance.example.com/api/google-health/
 
 The Google Cloud client id/secret are per-user (Settings), not env vars.
 
+## Backfill, the hourly sync and Google's rate limit
+
+Only one sync runs per account at a time. While the history backfill that
+follows a connect is running, the hourly sync leaves that account alone, and
+**Sync now** reports that a sync is already in progress and shows its progress
+instead of starting a second one.
+
+Google limits how many requests one account may make per minute. When a sync
+reaches that limit, Google answers `429`, and HealthLog waits and repeats the
+request; the connection is never marked as needing a reconnect because of it.
+Access tokens last an hour, and a long backfill renews its token as it goes.
+A backfill that stops part-way (a restart, the job's time budget) picks up
+with the data types it has not finished yet on its next attempt.
+
+If an older version left your Google Health card asking for a reconnect after
+a backfill, the first sync after updating checks the stored grant and resumes
+on its own when the grant is still valid.
+
 ## The 7-day re-consent caveat
 
 While the OAuth consent screen stays in **Testing** publishing mode, Google