Thank you for sounding the alert!
I identified a minor issue with your otherwise nice explanation: According to my sources (man cryptsetup, #rfc9106), all #argon2 varieties are memory-hard. RFC 9106 is even titled “Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications”.
However, given that there are known attacks against #argon2i, it seems wise to use #argon2id instead. It is also what is recommended in the RFC.
As a #QubesOS user, I just checked the state of affairs there:
The cryptsetup that comes with QubesOS 3.x used #luks1, and those who did an in-place upgrade to 4.x still have that unless they converted to #luks2 manually (as detailed in the migration guide).
The cryptsetup in QubesOS 4.x uses #luks2, but it still defaults to #argon2i unfortunately.