Odd cases of rest placement

Issue type

UX/Interaction bug (incorrect behaviour)

Bug description

Automatic placement of rests could be incorrect and also difficult to change manually (by mouse dragging).

Steps to reproduce

1. Treble clef, 4/4, enter stacked vertically as a "cord"
2. Voice 1, quarter E5 (stem up after step 3)
3. Voice 2, quarter rest (nicely under E5)
4. Voice 3, quarter C4 (stem up)

Though there is seemingly enough space between the notes, at step 4 the rest jumps up one line and partially overlaps E5.
Attempts to move the rest down often fail; usually it helps to shift slightly sideways rather than just down.
But most of the time it snaps back.
When dropped over the stem of C4, the rest jumps up and completely hides the stem of E5.

The other quarter rests could be moved up or down manually, but only in steps of a distance between staff lines - such granularity would be appropriate for half and whole rests.

And the weirdest were half rests.
When dragged up or down, voices 2 and 3 half rests would jump from the drop position: voice 3 lands precisely 2 lines below, and voice 2 goes up one line. Voice 4 jumps 1 line down. Only voice 1 half rest stays where it was dropped.
But none of these rests were moved in line distance steps.
For example, if voice 3 rest was dropped under the line 4, the brick will be seen under the line 2 representing a whole rest.

MuseScore Version

4.2.1

Regression

I don't know

Operating system

Windows 11

Reproduce the stacked-voice rest placement and dragging cases in MuseScore 4.2.1 using the stated treble-clef, 4/4 example. Investigate why quarter and half rests snap to unexpected staff-line positions or overlap notes; done means automatic placement avoids overlap and manual dragging retains the intended line-distance position.