Btrfs rollback only works if the layout was designed for it. Snapshotting a subvolume that contains /var/log and the package cache means rolling back the logs of the failure you are trying to diagnose.
1. A layout that separates state from system
btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home
btrfs subvolume create /mnt/@log
btrfs subvolume create /mnt/@pkg
btrfs subvolume create /mnt/@snapshotsMounted as /, /home, /var/log, /var/cache/pacman/pkg and /.snapshots. Now a root snapshot contains the system and nothing that should survive a rollback independently.
2. Snapshot before the risky thing
btrfs subvolume snapshot -r / /.snapshots/pre-upgrade
btrfs subvolume list -s /Read-only snapshots cannot be modified in place, which is what makes them trustworthy as a restore point.
3. Rolling back
# from a live USB or the initramfs shell
mount -o subvolid=5 /dev/nvme0n1p2 /mnt
mv /mnt/@ /mnt/@broken
btrfs subvolume snapshot /mnt/.snapshots/pre-upgrade /mnt/@Keep @broken until the machine is confirmed healthy, then delete it. It is the only copy of the state you would need to work out what actually went wrong.
4. Maintenance nobody mentions
btrfs scrub start /
btrfs filesystem usage /
btrfs balance start -dusage=50 /A filesystem that reports free space while refusing writes is almost always unbalanced allocation, not a full disk. Run a filtered balance before believing df.