I'd freeze it, and I'd have the server enforce the freeze rather than the dialog. The confirm request should carry the exact IDs from the preview plus the version each record had when it was shown. The server acts on those IDs only, skips any whose version changed or that stopped being eligible, and returns the skipped list, so "Deleted 19 of 20, 1 changed since preview" is something the API reports instead of something the UI guesses.
For "all matching records", I'd send the filter together with the count the user saw, and have the server refuse with a 412 if the filter now matches a different number. It's the same idea as If-Match: the user approved a specific state, and the write fails when that state has moved. Export is where I'd relax it. Re-running an export costs nothing, so a live filter with the real count in the file name is fine. A delete you can't undo should only ever touch the reviewed set.