Provide info on how many participants are in a snapshot

[alexsb]

Is this possible?

---

Specification

Added after specification review.

Summary

Show participant status counts for each snapshot in the Manage Data Snapshots table. The counts should use the same completed, in-progress, and rejected breakout used for live participant summaries, but the change should apply only to snapshot rows.

Decisions

• Add three snapshot table columns: Completed, In Progress, and Rejected.
• Use the same participant status definitions as live analysis:
  • Completed: participant.completed && !participant.rejected
  • In Progress: !participant.completed && !participant.rejected
  • Rejected: participant.rejected
• Apply this only to snapshots. Do not change live data management controls as part of this issue.
• Store snapshot status counts on snapshot metadata so the table does not need to fetch every snapshot's participants on every load.
• When creating a new snapshot, compute and save the counts with the snapshot metadata immediately.
• For existing snapshots that do not have count metadata, lazily fetch that snapshot's participants, compute the counts, persist them back onto the snapshot metadata, and update the displayed row.
• If counts are missing, loading, or being backfilled, show a per-cell loading or fallback state without blocking snapshot actions.

Suggested metadata shape:

type SnapshotParticipantCounts = {
  completed: number;
  inProgress: number;
  rejected: number;
};

type SnapshotDocContent = Record<string, {
  name: string;
  participantCounts?: SnapshotParticipantCounts;
}>;

Acceptance Criteria

• The snapshot table has Completed, In Progress, and Rejected columns.
• Counts use the same completed, in-progress, and rejected definitions used for live participant summaries.
• Newly created snapshots save participant counts into snapshot metadata.
• Existing snapshots with no counts are backfilled by fetching that snapshot's participants, computing counts, saving them to metadata, and updating the row.
• Existing snapshot actions still work: rename, restore, delete, and downloads.
• Rename preserves the snapshot's stored counts.
• Delete removes the snapshot metadata as before.
• Count fetch or backfill failures do not break the table; affected cells show a clear fallback and actions remain usable.
• Unit tests cover rendering stored counts and backfilling missing counts in DataManagementItem.

Out of Scope

• No live-data UI changes.
• No status filtering or drill-down from these columns.
• No migration script for old snapshots; lazy backfill is sufficient.
• No total participant column unless separately requested.

Implementation Notes

• Extend snapshot metadata to optionally include participantCounts with completed, inProgress, and rejected numeric fields.
• Prefer a shared helper for computing counts from snapshot participants so the create-snapshot and lazy-backfill paths cannot drift.
• Preserve existing snapshot action behavior and the current snapshot download path.

Testing Notes

• Add or update unit tests near DataManagementItem.
• Cover snapshots with existing metadata counts.
• Cover snapshots without counts, including successful lazy backfill.
• Cover a failed count/backfill fetch to verify the table remains usable.