[Dashboard] Manage, annotate, and compare persisted runs/recordings

Start by reading the current Run persistence implementation and its handling of StartedAtUtc, EndedAtUtc, and CleanShutdown; the issue says each run has its own dashboard.db. The request spans dashboard run management, annotations, comparisons, lifecycle facts, storage accounting, and API/CLI exposure, so identify the existing run list and recording API/CLI entry points before narrowing scope. Done means a focused implementation defines its artifact model and preserves telemetry and lifecycle facts while supporting the selected management and investigation workflow.

Is there an existing issue for this?

• I have searched the existing issues.

Is your feature request related to a problem? Please describe the problem.

Persisted dashboard runs should be useful investigation artifacts, not just databases users can revisit. After finding an interesting failure or performance change, I want to name the recording, explain what happened, attach context to the relevant resource or telemetry, and compare it with other runs.

I also need control over the recordings consuming my disk: discover their size, decide what to keep, and remove what I no longer need without manually editing the dashboard's storage directories.

Describe the solution you'd like

Provide a coherent dashboard experience for managing, annotating, and comparing persisted runs/recordings:

1. Manage recordings. List and search saved runs with their time range, size, and retention/pin status. Rename them; edit user-facing metadata such as title, description, and tags; and pin/unpin. Delete a single saved run directly from the dashboard, with a per-run delete action and confirmation identifying the run being removed; do not require CLI commands, manual filesystem cleanup, or deleting all history. Remove that run's data, metadata, notes, and attachments, refresh the run list, and safely leave the deleted run's view. Report failures explicitly and define safeguards for active or in-use runs. Keep technical identity, original timestamps, and captured telemetry intact when editing metadata. Show whether deletion actually reclaimed storage.

2. Capture investigation context. Add run-level notes and annotations attached to resources, console/structured log entries, traces/spans, metric instruments or chart time ranges, and relevant dashboard views. Support attaching supporting details such as reproduction steps, issue/PR links, screenshots, or other files. Make annotated locations easy to revisit instead of relying on remembered filters or external notes with fragile references.

3. Compare two or more recordings. Select a baseline and one or more other runs, then compare resource/configuration changes and relevant telemetry: errors, representative request traces, and metric trends. Allow users to choose comparable resources, operations, and time windows, including alignment relative to run start rather than only absolute clock time. Surface differences in workload, duration, sampling, retention, or missing data so that the comparison does not imply equivalence where none exists.

4. Make run facts easy to retrieve. Show each run's start time, stop/end time, duration, and status in the run list and details, and expose them through the recording API/CLI for automation. Distinguish the run lifecycle from the first/last telemetry timestamps. For active runs, show "running" rather than a fabricated stop time; for an interrupted run whose end was not recorded, show an unknown end/unclean shutdown rather than treating the last telemetry event as the actual stop time.

   Show storage usage in bytes and a readable unit, with a breakdown for the main database, WAL/other sidecar files, and metadata/attachments, plus the total recording footprint. In the current Run persistence implementation, each run has its own dashboard.db, so its file size can be measured directly; estimating the size of a subset of rows is not necessary. A live size is a sampled value and should be identified as such. For future/shared stores or logical recordings within one database, distinguish estimated logical data size from physical file usage, and do not present an estimate as exact reclaimable space.

Example: preserve a failing run, rename it "Failure before configuration fix," annotate the problematic span with a hypothesis and issue link, attach reproduction details, and compare it with the fixed run and a known-good baseline. Later, remove unrelated recordings while keeping that investigation.

Design considerations

• Separate editable user metadata and annotations from captured telemetry. Editing a title or note must not rewrite the original evidence or alter schema/identity fields.
• Reuse the existing run metadata (StartedAtUtc, EndedAtUtc, and CleanShutdown) where applicable. Preserve original lifecycle facts separately from user-editable descriptions, and document what the recorded start/end events represent.
• Give annotations stable run-scoped targets, not just row positions or current UI filters. Define behavior when referenced telemetry is evicted, a recording is deleted, or an imported recording has a different schema. Do not silently attach notes to a different event.
• Decide how notes and attachments travel with export/import and how a selected view/time range is represented. Account for schema compatibility and avoid silently discarding investigation context.
• Include metadata and attachment sizes in storage accounting. Define whether annotations protect their referenced data from eviction or simply report that the original data is no longer available; do not let annotations create an implicit unlimited-retention loophole.
• Validate attachment types/sizes, render notes safely, and treat saved context as potentially sensitive. Apply the same access controls and deletion lifecycle as the recording.
• Keep the initial implementation focused: recording metadata/lifecycle and notes first, with targeted annotations and comparison building on the same artifact model. This request does not require implementing every possible diff view at once.

Additional context

Related requests, with distinct scope:

• #21901: genuine disk opt-out and bounded live storage. Managing intentionally persisted artifacts should not be required to avoid writing live telemetry to disk.
• #20601: snapshot-and-clean without restarting, including named snapshots and local/CI comparisons. Coordinate comparison and recording terminology with that proposal rather than duplicating snapshot creation here.
• #20578: CLI/agent access to previous runs. A consistent recording identity and metadata model should support those consumers.
• #21047: per-trace summaries and comparisons grouped by attributes. This request concerns cross-recording investigation context and lifecycle; reuse compatible comparison primitives.

This is a separate feature request from the persistence opt-out bug: users should be able to decline disk storage, and users who deliberately retain recordings should be able to manage and enrich them.