fix(backup): carry the intraday day shape through export and restore

`IntradayCumulativeProfile` shipped classified as backed up and carried by
nothing. The drain folds the per-sample rows into twenty-four running totals
and deletes the originals in the same transaction, so past the grace window
the table is the only copy of a day's curve: a restore rebuilt the account
without it, reported success, and left the same-time baseline reading "still
learning" for a fortnight.

Builder and restore sit together in one file, the way the profile and cycle
pairs do, because the restore route delegates and a grep of the route alone
lies. The section spreads into the payload rather than being copied key by
key. Two curves for the same metric and day, or a curve that is not a whole
day, throw naming the day instead of writing a row every reader drops.

The pair is proven end to end rather than at each end: the round-trip suite
builds a real payload from a populated account, serialises it, parses it back
through the real parser, drives the real restore, and asserts on the rows
written. Remove the read and it goes red.

src/components/admin/backups-section.tsx

@@ -246,6 +246,7 @@ export function BackupsSection() {
           healthProfile?: number;
           customMetrics?: number;
           customMetricEntries?: number;
+          intradayProfiles?: number;
         };
       }>("/api/admin/backups/upload", { method: "POST", body: fd });
     },
@@ -272,7 +273,8 @@ export function BackupsSection() {
         (data.summary.nutrientDays ?? 0) +
         (data.summary.healthProfile ?? 0) +
         (data.summary.customMetrics ?? 0) +
-        (data.summary.customMetricEntries ?? 0);
+        (data.summary.customMetricEntries ?? 0) +
+        (data.summary.intradayProfiles ?? 0);
       toast.success(
         t("admin.section.backups.uploadSuccess", { count: String(total) }),
       );