Override cursor handling in spinbox and autocommit is buggy ...

... at least in theory: I did not try to reproduce the bug, I just see it in code. We fall into the same trap as this guy: https://stackoverflow.com/questions/66185831/pyqt5-how-to-restore-the-default-cursor-after-multiple-overrides

Whenever we override an application-wide cursor, these go onto a stack. For example, if anything overrides the cursor while you are dragging in the spinbox, then after drag the overridden cursor will not be restored.

I do not see a safe use of override cursors. As a hack, restores could become something like the following, which guarantees that the default cursor will always be restored.

```
while QApplication.overrideCursor() is not None:
QApplication.restoreOverrideCursor()
```

To use it, we would also need to be sure that `QApplication.restoreOverrideCursor()` does crash if the current stack is empty (because this code could clean someone else's cursor).

So I'd avoid override cursors completely. SpinBoxes could probably be rewritten to capture the mouse and then use `.setCursor` on themselves.

Start by tracing the spinbox drag handling and its uses of QApplication.overrideCursor() and QApplication.restoreOverrideCursor(). Compare the behavior described in the issue with the proposed setCursor approach; done means overridden cursors are reliably restored after dragging, including when another cursor override occurs.

Written by the indexing model from the issue text.