fix: discussion window teardown and a recursion guard

[seflue]

Three unrelated bugs, all found while working on #577.

A discussion window that can't be closed

Every so often gld leaves a discussion window on screen. It has to go by hand, and toggling again opens a new one beside it.

M.close cleared split_visible regardless of whether anything had been closed. From then on the plugin considered the tree gone while its window was still there, and the next toggle mounted a second one beside it.

NuiSplit:unmount() raises an internal loading flag before _buf_destroy() and _close_window() and clears it only once both return. An error in between leaves the object loading for good, and every later unmount() returns early without closing anything. One trigger is E444: Cannot close last window, raised inside _close_window when the split is the last window in the session. After that nui cannot close that tree at all.

M.close now closes the window itself when the split does not, and keeps split_visible set for as long as the window is alive; the WinClosed handler defers to the next tick, so the buffer wipe still fires BufWipeout. Whether that is the path behind the issues I observed I can't say; any error in between does it. #308 shows the same nui failure from the popup side.

A second window can also appear without any of this, when something splits the tree's window and the split keeps its buffer. That one is not addressed here, though the buffer release below does clear it up on the next toggle.

get_root_node can hang Neovim

Every reply in the tree is a node with type = "note" and no is_root, and get_root_node walks those up to their root. On a node without a parent, get_parent_id() returns nil and the walk calls tree:get_node(nil). NuiTree reads a missing id as "the node under the cursor" and hands back the node we started from. The recursion sits in tail position, so the stack never grows and nothing is raised: Neovim spins until you kill it.

get_note_node already returns nil on a missing parent, get_root_node does not. Every non-root note node currently sits under a root, but nothing enforces that. Both callers already report a nil root as an error, so returning nil is enough to make the failure visible. I ran into this while writing a test, which hung instead of failing.

Two leaked buffers per open/close cycle

:ls fills with stale gitlab buffers over a session. create_split_and_bufs allocates a fresh linked/unlinked pair on every open and nothing ever released the previous one. They are listed buffers, so until now you could reach a closed discussion tree again with :bnext, but after this you can't.

[jakubbortlik]

I've suggested some modifications to the docstrings/comments and expressed some remaining uncertainty. I don't mean to be nitpicky, trying to understand and hopefully make the comments more useful for other contributors as well :)

[jakubbortlik]

One last thing (promise 🤞) . Last time I used tour branch the gld gld cycle of closing and reopening the split still seemed to leave some orphaned buffers behind (not sure though if that was gitlab.nvim's fault or some other plugin, I didn't try with a clean install and only the necessary dependencies).