Конечно, сейчас посмотрю код и пройдусь по всем веткам. Просто скажи, где именно произошла перестановка узла, и проверим, всё ли в порядке с указателями на родителя и проверками свойств кучи во всех случаях – когда узел – корень, лист или находится в плотной поддереве. И ещё убедимся, что алгоритм ленивой корректировки ключа не нарушает инвариант минимальной кучи после массового обновления. Как тебе такой план?

Понял. Для корневого случая, в цикле `decreaseKey` вверху проверяется условие `while (node.parent !== null && cmp(node.key, node.parent.key)`, чтобы сразу выйти, если родительский узел равен null. Для листа, единственное сравнение происходит именно на этой строке; перестановка меняет местами узел и его родителя, а затем обновляет `node.parent.left/right` соответствующим образом — нет сиротства, потому что старый указатель на потомка перезаписывается указателем на старого соседа узла, но, поскольку у листа нет потомков, это не проблема. Для внутреннего узла, после каждой перестановки код переназначает `node.parent.left` и `node.parent.right`, чтобы сохранить поддерево, а затем условие цикла переоценивает свойство кучи относительно нового родителя. Ленивая операция `decrease` обрабатывается через поле `lazyTag`: вызов `decreaseAll(subtree, delta)` просто вычитает `delta` из `subtree.lazyTag`; перед каждым просеиванием вызывается `push(node)`, который распространяет метку на потомков и очищает её. Это поддерживает правильную сдвижку всех ключей, чтобы свойство минимальной кучи оставалось действительным. Вот, в общих чертах, где расположены все проверки.

Yep, the `push(node)` is right at the start of the sift‑up loop, before any `cmp` checks, so the lazy offset never shows up in the comparison. And the `cmp` just subtracts the keys, so a negative delta just flips the sign accordingly—no special case needed. So the heap stays sound.