vs. dm-verity

Yes, that's correct. The early firmware is fully verified from a hardware root of trust, followed by vbmeta being verified by the late stage bootloader which then verifies the hashes of boot (and dtbo if present) from there. The system and vendor partitions are verified via dm-verity, bootstrapped from hashes in vbmeta. That's all read-only at boot, and is never directly written. Updates write to the alternate partition set (for firmware and the OS partitions), and then a reboot into the new version is done by switching to the new partition set, which has already been verified by the updater before marking it as usable (in case a write error occurred) and then gets verified again by verified boot. The fs-verity support is used to verify dynamically updated components in the rw userdata partition.