fix(db): aggregate multi-service project policy batches in latestByPolicy (#730)

[chbndrhnns]

Fixes #730

Problem

When a backup policy targets an entire project (serviceId === null), triggering the policy fans out and creates a batch of concurrent backup_run rows (one for each enabled service in the project).

However, repos.backupRun.latestByPolicy(policyId) previously ran a single findFirst query ordered by startedAt DESC, returning only the single child run that happened to be inserted last (e.g., 122.0 KB from Redis in a multi-service project).

This caused two issues in the Destination details page (/backups/:id) and Jobs view (/jobs):

1. Misleading Stored Size: The policy row displayed only a fraction of the backup size (122.0 KB), contradicting the Destination Total Stored rollup (29.8 MB).
2. Inaccurate Status: The policy row status reflected only that single child service run rather than the composite outcome of the project's backup batch.

Solution

1. Batch Window Aggregation in latestByPolicy: In packages/db/src/repos/backup.repo.ts, latestByPolicy now locates the newest run and finds all sibling runs for the policy within a 60-second window around startedAt (the execution batch).
2. Consolidated Metrics:
   • bytesTransferred: Sums transferred bytes across runs in the batch.
   • status: Resolves composite status (in-flight if any run is running; failed if any run failed/errored/cancelled; succeeded if all succeeded).
   • startedAt: Earliest startedAt in the batch.
   • finishedAt: Latest finishedAt in the batch (or null if any run is in-flight).
3. Tests: Added comprehensive test suite in packages/db/src/repos/backup-latest-by-policy.repo.test.ts verifying single-run policies, multi-service batch aggregation, failure status propagation, in-flight state handling, and batch isolation from historical runs.