you already seem to have figured out how to get your system bootable again, so I'll only answer this part here.
the problem is that Grub basically comes with its own set of filesystem drivers (or rather, parsers), since it runs before the kernel/actual OS gets executed. those drivers are of varying quality, and often lag behind with regards to the features they support. with ZFS the support was never good, and in addition it hasn't really kept up with developments on the ZFS side. the result is a buggy driver that requires a lot of care to get somewhat working, with bugs still lurking that might break booting with *any* write to the pool where your Grub stage2, kernel or initrd (basically, any file that Grub itself needs to read to boot) resides.
that's why we switched to no longer let Grub read from ZFS at all, but
- put the kernel and initrd on the ESP (even when not booting using EFI!)
- using systemd-boot or grub installed onto that ESP (which one is used depends on whether EFI and Secure-Boot are enabled or not)
in practice this means that Grub now only has to read from the ESP, which is vFAT formatted, which is in turn a very simple file system with a good driver on the Grub side and very little risk of regressions compared to the ZFS one. for LVM (ext4/xfs), we still use the regular /boot on / approach since that works and is a very widespread and well-tested setup.
the ESP doesn't contain any data that is not also stored on the rootfs, so in practice if the ESP is lost it can easily be recreated, but booting would be temporarily broken in that case just like it was for you now. with proxmox-boot-tool you can manage redundant ESPs to minimize the risk.
