behn: propagate errors in deferred moves

[joemfb]

... and handle them correctly in the only remaining %drip-sites in %clay.

This has been tested and validated in various upgrade scenarios between local fake ships. It was motivated by a case of .^ in +on-load rendering a ship effectively inoperable (behn: queue blocked).

[philipcmonk]

I didn't realize those were the last callsites, that's good to see. These changes are good.

[philipcmonk]

Leaving a note for posterity:

I believe this caused an issue with a ship that had something in its set of drips when the upgrade went through (since drips happen during the upgrade process, this isn't that surprising). Other ships may have had that situation, but drips don't usually fail. This one did because the drip was to install an old clay revision that didn't have a sys.kelvin. This caused the queue to block.

[joemfb]

I never thought to migrate outstanding %drip's along with this change. Did you find a workaround, or do you think it's worth writing and deploying a migration to better support upgrading old ships? (That would just transform the ducts of any outstanding %drip's from %clay.)

[philipcmonk]

I don't think it's worth it unless we find another reason why it would deterministically fail. The sys.kelvin trigger only really might happen if you're upgrading from before October 2021, and that's not many.

In our case, breaching the ship is not a big deal, so we're doing that.