feat(macos): Refine MacOS surface drag handle UI

[martinemde]

This PR makes 3 small changes:

1. Makes the surface move grab handle present when the surface is hovered and the mouse cursor is not hidden.
2. Makes the grab handle partial width, allowing space to more easily grab the divider for resize (anywhere but the center) and increasing the grabbable area for the grab handle.
3. Adds appropriate padding to the top of the surface (in the metal stack so shaders can apply) to give space for the header so that text is not occluded by the grab handle.

I think it looks good and works well, but I suggest trying it out since the interaction is the most important part.

Problems I was trying to solve:

1. The old grab bar overlays actual clickable area on TUIs and can make them hard to use
2. The old bar makes the entire divider also a grab area, making divider resizing more difficult.
3. The old bar is not always present, making it hard to discover until you're going to resize something, which then is confusing
4. The old bar is not colored with the style.

Screen.Recording.2026-01-15.at.10.55.41.AM.mov

AI Disclosure: I originally did this with Claude, but at this point I've gone over this code manually enough to feel somewhat familiar. I think the video and design speak for themselves and the code change is minimal, but I'm not a Swift programmer, so I can't evaluate whether this is the best possible solution.

Human Disclosure: I don't have a linux machine to check that the padding doesn't apply outside of MacOS. I find it hard to believe that it wouldn't work, but worth calling out.

[tristan957]

Not sure I love this extra space always existing. I am more in favor of holding down a modifier while hovering the grab handles. It's been discussed elsewhere too.

[martinemde]

Updated movie with the size adjustment.

[edrozenberg]

Not sure I love this extra space always existing. I am more in favor of holding down a modifier while hovering the grab handles.

Agree, wouldn't want to take any space away from content, or (different idea) to shift content down temporarily (shifting content is distracting and bad).

An overlay that appears either with a delay or special keystroke seems like the best option along with the option to completely disable the overlay via config such that those who don't need or want the functionality never have to see it under any scenario.

[martinemde]

In practice, I'm using about 4pts of font size in height, it's less than is often wasted by the space at the bottom of the terminal, though there's theoretically a pathological spacing where you lose a line of text because of this spacing.

What I'd honestly suggest is that people pull this down and build it and see if they actually don't like it, and which one feels better. The current solution isn't just confusing, but actively harms usability of TUIs and resizing of panes by dragging. Whatever the solution, I don't think the current incarnation is right.

I'm happy to try to test out some ideas or make multiple branches that people can try, but I assure you that until you use the interaction in person, the videos don't do any of them justice. Case in point, the practical lost space of even 3 panes worth of header space is virtually invisible. The additional header space feels better to me even ignoring the .... After using it, I feel like the text is too close to the top bar without it.

My point is: "press a key to show the grab handle" seems right until you try it, then it's jarring and confusing. "There's always a header space that's taken away from your terminal" sounds wrong until you use it, but it's actually kind of nice.