feat(integrations): tell the Apple Health card how the last sync arrived

The batch route has accepted a `syncTrigger` since v1.32.8 and put it on the
wide event, where no human reads it. Half of what was promised got built: the
value is written and appears in three places in the codebase, none of which is
a screen anyone looks at.

Persist it on the account, alongside the instant of the most recent batch that
arrived without the app being opened, and publish both from
`GET /api/integrations/healthkit`. The card now names how the last sync arrived
and when data last came in on its own. `healthKitLastSyncedAt` alone reads
identically whether the phone delivers by itself or only while someone has the
app open, which is why "is background delivery working" could not be settled
from either side.

A batch that declares no trigger writes null rather than leaving the previous
one standing — the field describes this sync, and an older client's silence is
not evidence about it. A foreground batch leaves the background timestamp
alone; overwriting it would erase the only answer the card has.

Also here: WHOOP, Fitbit and Google Health join the workout-freshness table.
All three write workouts, and without an entry their cards could report every
measurement type fresh while the workout leg had been silent for weeks. And the
status pill drops a generic `aria-label` that replaced its own accessible name,
so a screen reader announced the same words for a healthy connection as for a
broken one.

src/app/api/integrations/healthkit/__tests__/route.test.ts

@@ -219,6 +219,8 @@ describe("GET /api/integrations/healthkit — sync health", () => {
 
   type Body = {
     lastSyncedAt: string | null;
+    lastSyncTrigger: string | null;
+    lastBackgroundSyncAt: string | null;
     syncHealth: { verdict: string; since: string | null };
     metricFreshness: Array<{
       type: string;
@@ -293,6 +295,38 @@ describe("GET /api/integrations/healthkit — sync health", () => {
     expect(byType.PULSE).toBe(false);
   });
 
+  // #586 — the reporter's question is whether the phone delivers on its own or
+  // only while the app is open. `lastSyncedAt` reads identically either way, so
+  // it cannot answer it; these two fields are what can.
+  it("publishes the trigger of the last batch and the last background arrival", async () => {
+    const backgroundAt = ago(3 * 60 * 60 * 1000);
+    vi.mocked(prisma.user.findUnique).mockResolvedValue({
+      healthKitConfigJson: null,
+      healthKitLastSyncedAt: ago(60 * 60 * 1000),
+      healthKitLastSyncTrigger: "background",
+      healthKitLastBackgroundSyncAt: backgroundAt,
+    } as never);
+
+    const body = await read();
+    expect(body.lastSyncTrigger).toBe("background");
+    expect(body.lastBackgroundSyncAt).toBe(backgroundAt.toISOString());
+  });
+
+  it("reports honest absence when the client has never declared a trigger", async () => {
+    vi.mocked(prisma.user.findUnique).mockResolvedValue({
+      healthKitConfigJson: null,
+      healthKitLastSyncedAt: ago(60 * 60 * 1000),
+      healthKitLastSyncTrigger: null,
+      healthKitLastBackgroundSyncAt: null,
+    } as never);
+
+    const body = await read();
+    // An older client that reports nothing, and a pipe that has never
+    // delivered in the background, both read as null — never as a guess.
+    expect(body.lastSyncTrigger).toBeNull();
+    expect(body.lastBackgroundSyncAt).toBeNull();
+  });
+
   it("degrades to no per-metric data rather than failing the config read", async () => {
     vi.mocked(prisma.user.findUnique).mockResolvedValue({
       healthKitConfigJson: null,