Upgrading through the web UI or tpi (the .tpu package) keeps the password and certificate. The only routes I found that reset them are the .img SD-card image and safemode, so DingoDogz probably flashes the image. I haven't confirmed that with them yet.

Why the password and certificate survive a normal upgrade

Both live on the board's writable storage (the overlay volume): the password in /etc/shadow, the certificate in /etc/ssl/certs/bmcd_*.pem.
A .tpu upgrade through the UI or tpi firmware replaces only the system image volumes and never touches that storage. Our own login survived the v2.40.0 and v2.41.0 upgrades that way.
The change-password page is real, not a stale-browser effect. It only appears when bmcd sees that /etc/shadow still accepts the factory password turing.
Two ways both get reset

The .img image on an SD card. It boots Turing's own installer, whose step "Formatting UBI partition" erases all of the board's flash storage and writes back only the system. On the next boot the password is turing again and a new certificate is generated. Node names and network settings are lost too. This would happen on every upgrade done this way, and it fits "4 nodes off" in the first report: an SD install needs a full power cycle, while a .tpu upgrade restarts only the BMC and the nodes stay up.
Safemode (KEY1 held at power-on, or the storage failing to mount). The board then keeps its settings in memory, so they reset on every boot, not only after upgrades.
A new certificate on its own, with the password kept, can also follow a .tpu upgrade. The script reissues the certificate when the board's addresses change, for example when DHCP hands it a different IP.

Why we never saw it: both our boards serve certificates from our own CA, which the script leaves alone, and we only ever upgrade with .tpu.