Just in case this bug report was unexpected, I've gotten a local backport build working.
This was enough to get the watchdog disabled during initramfs. However, I had to take a couple of extra steps to get it fully operational. I created /etc/udev/rules.d/70-gpio_keys-for-systemd.rules: ACTION=="remove", GOTO="gpio_keys_end" SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="platform", DRIVERS=="gpio-keys", TAG+="systemd" LABEL="gpio_keys_end" so that systemd knew about dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device. Otherwise it would timeout waiting for it when the qcontrold service was asked to start. (This might not be necessary in Buster? I didn't try udev from stretch-backports.) This timeout made the install fail, although even in the failed-to-install state, the initramfs was updated so I stopped getting the 'unexpected 0 from a125' error from the watchdog. I also had to disable auto-generated serial agetty: systemctl mask serial-getty@ttyS0.service as it seemed to want to steal /dev/ttyS0 and interfere with qcontrold startup. This is probably not a qcontrold problem per-se, but possibly related to the systemd upgrade (I just came from Wheezy via Jessie). The latter might be fixed by having qcontrold be required to start before the serial-getty@ttyS0.service, so that its TS-41x lua script gets a chance to decide if ttyS0 is for getty or for a125, and can perhaps itself ensure that getty@ttyS0.service state is correct for the current jumper setting. I don't know how to express that in systemd, and looking at the systemd-getty-generator manpage [1], I think the problem is that despite lack of a `console=` kernel command-line, the kernel log shows it taking ttyS0 as the kernel console, and system-getty-generator is doing what it's supposed to do there, drawing from /sys/class/tty/console/active. Anyway... Now my dhclient exit hooks are happily updating my LCD screen with my IP address on boot. ^_^