Roll the table back, but read the preview first

A bad deploy wrote garbage to a few hundred keys between 14:10 and 14:25. Point-in-time recovery on a hosted database usually means restoring a fork and reconciling by hand. Here the table can walk itself back. First the preview: POST /api/v1/sqlite/kv/rollback?to_timestamp=1755871800&dry_run=true returns the keys that would change, without touching anything. You read the list, confirm it's the damage and only the damage, then run it again with confirm=yes. The store replays its operation log and the table is 14:09 again.

The two-step is the point. A rollback you can read before you run is a rollback you'll actually run at 14:31, not after an hour of deliberation.