systemd-repart (mostly) operates in a purely incremental mode: it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions. The service is intended to be run on every boot, but when it detects that the partition table already matches the installed repart.

{
  boot.postBootCommands = ''
    # On the first boot, resize the disk
    if [ -f /disko-first-boot ]; then
      set -euo pipefail
      set -x
      # Figure out device names for the boot device and root filesystem.
      rootPart=$(${pkgs.util-linux}/bin/findmnt -n -o SOURCE /)
      bootDevice=$(lsblk -npo PKNAME $rootPart)
      partNum=$(lsblk -npo MAJ:MIN $rootPart | ${pkgs.gawk}/bin/awk -F: '{print $2}')

      # Resize the root partition and the filesystem to fit the disk
      echo ",+," | sfdisk -N$partNum --no-reread $bootDevice
      ${pkgs.parted}/bin/partprobe
      ${pkgs.bcachefs-tools}/bin/bcachefs device resize $rootPart

      # Prevents this from running on later boots.
      rm -f /disko-first-boot
    fi
  '';
  disko = {
    extraPostVM = ''
      ${pkgs.zstd}/bin/zstd --compress $out/*raw
      rm $out/*raw
    '';
    devices = {
      disk = {
        disk1 = {
          imageSize = "10G";
          type = "disk";
          device = "/dev/mmcblk0";
          postCreateHook = ''
            lsblk
            sgdisk -A 1:set:2 /dev/vda
          '';
          content = {
            type = "gpt";
            partitions = {
              firmware = {
                size = "30M";
                type = "EF00";
                content = {
                  type = "filesystem";
                  format = "vfat";
                  mountpoint = "/firmware";
                  postMountHook = toString (pkgs.writeScript "postMountHook.sh" ''
                    (cd ${pkgs.raspberrypifw}/share/raspberrypi/boot && cp bootcode.bin fixup*.dat start*.elf *.dtb /mnt/firmware/)
                    cp ${pkgs.ubootRaspberryPi4_64bit}/u-boot.bin /mnt/firmware/u-boot-rpi4.bin
                    cp ${configTxt} /mnt/firmware/config.txt
                  '');
                };
              };
              boot = {
                size = "100M";
                content = {
                  type = "filesystem";
                  format = "ext4";
                  mountpoint = "/boot";
                };
              };
              root = {
                name = "root";
                size = "100%";
                content = {
                  type = "filesystem";
                  format = "bcachefs";
                  mountpoint = "/";
                  postMountHook = toString (pkgs.writeScript "postMountHook.sh" ''
                    touch /mnt/disko-first-boot
                  '');
                };
              };
            };
          };
        };
      };
    };
  };
}

Is this perhaps another way that disko's architecture fails because of the hostPlatform issue?

corpo-disko-images> qemu-system-aarch64: could not load kernel '/nix/store/fqwx7jpif67dzqhiggnnj69nhch8jp23-kernel-modules/vmlinuz.efi'
error: build of '/nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv' on 'ssh-ng://matthewcroughan@aarch64.nixos.community' failed: builder for '/nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv' failed with exit code 1;
       last 2 log lines:
       > unable to handle EFI zboot image with "zstd22" compression
       > qemu-system-aarch64: could not load kernel '/nix/store/fqwx7jpif67dzqhiggnnj69nhch8jp23-kernel-modules/vmlinuz.efi'
       For full logs, run 'nix log /nix/store/zzvgpqhc34ha13p2a70l2s5ya324safa-corpo-disko-images.drv'.