gptzfsboot can't boot from 4TB SSD

Hey folks, I'm stumped on what I assume is a BIOS bug...

Upgraded a system from 2013 and a 60GB SSD with UFS (plus GELI and ZFS) 
with a shiny new 4TB Samsung SSD, on ZFS and with some parts of the pool 
encrypted.

This was fine for half a year or so, but I noticed a stream of `zio_read 
error 5` from boot0 (I think?) sometimes during boot on the serial 
console, but it came up fine anyway.

Did another installworld/installkernel dance yesterday and the system no 
longer boots. First it was showing streams of that zio_read error, then 
failed to load /tank/ROOT/default:/boot/kernel/kernel. Using the '?' 
command I could see / just fine, but I could get no combination to work 
to read inside dirs, the manpage makes me think I should try /boot?, but 
maybe I should've added a space?.

Typed in /boot/kernel.old/kernel (!) and it started the spinner, but 
died shortly afterwards.

Put the SSD into a different system (from ca. 2014) and it boots up just 
fine. Put the old 60GB SSD back in the old system, and it also boots 
just fine.

Ok, on the newer system, I re-wrote the bootcode with `gpart bootcode -b 
/boot/pmbr -p /boot/gptzfsboot -i 1 ada0` but that seems to have made 
things even worse on the old system. Now the tank pool isn't even found 
anymore (due to the protective MBR maybe?), all I get is some zio_read 
errors and (from memory, sorry):

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool tank

Issuing '?' finds nothing anymore.

My hypothesis is that this worked initially, as the loader was under 
some specific LBA threshold, but with more data on the disk, every 
update moved it back further and this triggers a BIOS bug.

There was even a BIOS update from 2018 that I flashed, but it didn't fix 
any of this, only some Intel ME bugs. Sigh.

This is what it looks like:

% gpart show
=>        40  7814037088  ada0  GPT  (3.6T)
           40        1024     1  freebsd-boot  (512K)
         1064         984        - free -  (492K)
         2048    33554432     2  freebsd-swap  (16G)
     33556480  7780478976     3  freebsd-zfs  (3.6T)
   7814035456        1672        - free -  (836K)

So can this be a shortcoming in the BIOS with large drives? I had 
thought that only applies to boot0, not the loader itself.

I thought I can maybe boot from an USB stick and have it find the root 
of the pool, but the CMOS battery is dead, so I can't switch the boot 
drive unattended. I can't even turn on UEFI boot as, due to the battery, 
it won't stick. And this being an "industrial" PC, the CMOS battery is 
actually rechargeable but soldered onto the board, so I would have to 
get that fixed as well.

Sigh. Should I try to switch to UEFI? Would I have to move all 4T around 
and re-partition, or could I steal 256M from the swap partition?

Should I try with, gasp, GRUB2?

I'm kinda stuck on GPT and BIOS here for a while, I think.

Thanks for reading all of that,
Uli