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

src/app/api/google-health/callback/route.ts

@@ -154,6 +154,9 @@ export const GET = apiHandler(async (request: NextRequest) => {
         // reconnect CTA and the sync path stops short-circuiting.
         needsReauth: false,
         backfillCompletedAt: null,
+        // A new grant walks history from the start: what an earlier
+        // backfill finished was read under the old one.
+        backfillProgress: Prisma.DbNull,
       },
       create: {
         userId: user.id,

src/app/api/google-health/sync/route.ts

@@ -104,6 +104,15 @@ export const POST = apiHandler(async (request: NextRequest) => {
   }
 
   const result = await syncUserGoogleHealth(user.id, { fullSync });
+  // Another run of this account holds it (the history backfill after a
+  // reconnect, or the hourly poll). Starting a second one beside it is what
+  // pushed accounts over Google's per-minute quota; the card follows the
+  // running one through the status route instead.
+  if (result.busy) {
+    return apiError("A Google Health sync is already running", 409, {
+      errorCode: "sync_in_progress",
+    });
+  }
   // A run that failed AND wrote nothing is an error, as it always was. A run
   // that failed after writing some of its resources is a partial, and answering
   // 502 for it threw away the honest half of the result.