fix(delete): stop asking Club Log to delete QSOs it never had

Deleting a selection with 'delete from the remote services' on took
minutes. Club Log was called for EVERY deleted QSO, uploaded or not, and
for the ones it never had it answers 403 -- a full network round trip per
contact, in series, on the goroutine the UI was waiting on. QRZ already
skipped records with no stored logid; Club Log had no equivalent guard.

Three changes, each fixing one part of the delay:
  - only contacts whose clublog upload status is Y or M are withdrawn;
  - the withdrawals run in the background, after a snapshot -- the local
    log is the operator's own copy and must not wait on two websites;
  - the hooks read the rows in one query instead of one per id, which on
    a remote MySQL logbook was 2 round trips per QSO before the DELETE.

Consecutive refusals now abort the run: Club Log blocks an account that
keeps sending requests it refuses, so working through the rest of the
selection only earns a longer block.

syncfolder.go

@@ -315,11 +315,11 @@ func (a *App) syncPublishDeletes(ids []int64) {
 	if store == nil {
 		return
 	}
-	for _, id := range ids {
-		q, err := a.qso.GetByID(a.ctx, id)
-		if err != nil {
-			continue
-		}
+	// One read for the whole set: see deleteSnapshot. Tombstones are written
+	// before the rows go, because a QSO that never had a sync identity has to be
+	// given one here — after the DELETE there would be nothing left to stamp.
+	for _, q := range a.deleteSnapshot(ids) {
+		id := q.ID
 		// A contact never touched since the sync was switched on has no identity,
 		// and giving it one now is what makes the deletion addressable at all.
 		a.syncMu.Lock()