Nexus instances thrashing over add/remove "remove_mupdate_override"

I'm not sure if this is important to fix, but in https://github.com/oxidecomputer/customer-support/issues/1372, after a MUPdate, we found a sequence of blueprints where presumably different Nexus instances (operating on different inventories) were thrashing about whether to add or remove the removal of a MUPdate override:

2026-05-14T12:17:13.553Z blueprint a96cbc0f-5a95-498c-bfe8-c1ea043aefcb, sled gen is 5, no "remove MUPdate override" present, everything at "install dataset"
2026-05-14T12:35:02.454Z blueprint 5e2024f9-3efa-4d82-8b05-9d927f460070, sled gen  5 ->  6: add removal of MUPdate override 829f8401-c4b5-4b1d-92db-5f7a23f166a0
2026-05-14T12:35:36.039Z blueprint 0086d64e-f586-44ea-bfe0-575b85e5414e, sled gen  6 ->  7: remove removal of MUPdate override 829f8401-c4b5-4b1d-92db-5f7a23f166a0
2026-05-14T12:35:37.488Z blueprint 5e7aecb3-c52a-48fb-b1da-fa5dea2dc8b7, sled gen  7 ->  8: add removal of MUPdate override 829f8401-c4b5-4b1d-92db-5f7a23f166a0
2026-05-14T12:35:38.393Z blueprint 6f3c2747-67a6-4c23-94c3-d3991b425773, sled gen  8 ->  9: removed removal of MUPdatre override 829f8401-c4b5-4b1d-92db-5f7a23f166a0

It converged on the right thing, as we'd expect.

Start by tracing Nexus blueprint generation and the MUPdate override handling described in the issue. Compare the logged blueprint and sled-generation transitions to determine why instances alternate between adding and removing the removal override. Done means identifying whether the thrashing is expected or fixing it so the sequence converges without unnecessary changes.