Check if qgroup exists before attempting to destroy it

[zfogg]

Summary

When a btrfs subvolume is deleted, its associated qgroup is often automatically destroyed by btrfs. Timeshift would then attempt to explicitly destroy the qgroup and fail with an error message like:

E: Failed to destroy qgroup: '0/276'

This happened because btrfs auto-destroys qgroups when their associated subvolumes are deleted. The previous fix in #458 made this non-fatal by returning true instead of false, but the error message was still printed, causing confusion.

Fix

This change checks if the qgroup still exists (using btrfs qgroup show) before attempting to destroy it:

• If the qgroup is already gone (auto-destroyed with the subvolume), we log a debug message and skip the destroy
• If the qgroup still exists, we attempt to destroy it
• If destruction fails (race condition), we log a debug message instead of an error

Testing

Tested on Manjaro Linux with btrfs quotas enabled:

• Before: E: Failed to destroy qgroup: '0/XXX' printed on every snapshot deletion
• After: No error message, clean output

Related Issues

• Fixes the symptom described in [BTRFS] Support for sqgroups / simple qgroups #354 (sqgroups/qgroups race condition)
• Improves upon Avoid unrequired syncs to speed up deletion #458 (which made the error non-fatal but still printed it)
• Related to Deleting snapshot takes too long with v25.07.5-1 #437