PLAN: the snapshot explorer, and the preview is gone

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

PLAN.md

@@ -293,10 +293,16 @@ something long in one, switch away and back, refresh — it's all still there.
   carries the rule it was taken under. The page **detects the existing cron job**
   (zfSnap, zfs-auto-snapshot, sanoid, or a bare `zfs snapshot`) and says so, warning if a Ham
   Lab schedule is running as well.
-  **Nothing is destroyed unseen.** Every schedule answers *what would it delete?* with the
-  list, sizes and dates, before Run now touches anything; only names that parse as a stamp
-  and a TTL are candidates, so a snapshot taken by hand is invisible to it; and a snapshot
-  deleted by hand needs its full name typed back.
+  **Nothing is destroyed unseen.** Only names that parse as a stamp and a TTL are ever
+  candidates for expiry, so a snapshot taken by hand is invisible to a schedule; Run now
+  says that expired snapshots go with it; and a snapshot deleted by hand is confirmed first
+  and needs its full name echoed back by the caller. (A "what would it delete?" preview
+  shipped and was removed the same day as redundant — Mitchell's call.)
+  The datasets table is a **snapshot explorer**: each dataset shows how many snapshots it has
+  and what they cost, and opens into the snapshots themselves — when each was taken, **when
+  it expires** (read from the TTL in its own name, so no server call), its size, and Delete.
+  Deleting takes the same-named snapshot on descendant datasets too, which is how a recursive
+  schedule made it.
   **A schedule is a real cron job** (2026-09-24, Mitchell's call after the first cut ran it
   from a ticker inside the daemon). Ham Lab writes `/etc/cron.d/hamlab-zfs`, owns it, and
   rewrites it whole on every change; each line calls `hamlab zfs-snapshot <id>` as the