fix(agenda): keep cursor on item after redo

[seflue]

ref #656, #868

Refreshing the agenda on save, as suggested there, calls agenda:redo('remote_edit', true) from a BufWritePost autocmd. After the refresh the cursor is positioned on the last line of the agenda window and the scroll position is gone. A todo state change from the agenda does the same whenever the edit adds lines to the file, for example the CLOSED timestamp on DONE. That is annoying: on a long agenda every state change loses the context around the item.

The cause: redo saved and restored the view of whatever window was current. The callers inside the agenda (filter, clock report) run with the agenda window current, and there it worked. From the write hook the current window is the org buffer, from a remote edit it is the hidden edit window. The restore then jumped to a line number in the agenda that was in fact the cursor line of the org file. When that number was larger than the agenda's line count, the cursor landed on the last agenda line.

With this patch, redo takes the view from the agenda window and remembers the headline under the cursor (filename plus :ID:, or the title when there is none). After the rebuild the cursor follows that headline, and the window scrolls only when the headline left the visible range. When the headline is gone from the agenda, the cursor stays on its line.

Two more things the write hook setup turned up:

• The headline is identified from data recorded when the agenda line was built. The OrgHeadline on the line points at tree-sitter nodes of the old parse; once lines were inserted above the item (a capture or refile into the same file), it describes a different headline.
• A todo state change from the agenda updates its line in place after the write. With a redo from the write hook in between, the in-place update matched by line number and overwrote a line of the fresh render. The item then appeared in both its old and its new block. replace_line now matches the line object; a line from an earlier render is not in the view and the update does nothing.

The last commit is separate: the guard that skips the automatic resize after a manual resize compared only the window's screen position (#219). A horizontal split opens above the current window, so making it taller changes nothing there, and every redo shrank it back. The guard now also compares the height.