Fixes #21084 by reverting to gtk_widget_event.

[masterpiga]

Fixes scrolling regression introduced by #21084.

Co-authored with Gemini.

Root cause

The commit replaced the native GTK3 scroll event propagation method (gtk_widget_event) with a custom function (_panel_scrolled) for scrolling the side panels via borders or modifier keys.

Instead of letting GTK's GtkScrolledWindow natively handle the scroll events and smoothly animate the view, _panel_scrolled explicitly manipulated the GtkAdjustment value.

This bypasses the built-in GTK kinetic scrolling engine, and caused every scroll event to instantly "snap" the panel to a new offset, leading to the jerky scrolling behavior.

Fix Details

• Reverted _panel_scrolled back to _borders_scrolled so that it uses gtk_widget_event() to forward GdkEventScrolls properly from the borders directly to the scrolled window.
• Modified the _scroll_sidebar proxy handler (which intercepts side panel scrolls when modifier keys are pressed) to again use gtk_widget_event instead of manually jumping the adjustment by calculating steps.

This ensures that the panels delegate the scroll events correctly, allowing GTK's smooth interpolation and native kinetic scrolling behaviors to work again.

This is a stopgap to address the regression, the fix is not GTK4 friendly.

Eventually, this will need to be rewritten, likely by restructuring the widget layout so that scroll events bubble up naturally to the GtkScrolledWindow, or by implementing a smooth interpolation mechanism for the scroll adjustments.

Also, note that the change that caused the regression has a much broader scope. This PR only undoes as little as possible to restore the correct scrolling behavior.

[masterpiga]

@dtorop @TurboGit

[TurboGit]

I cannot reproduce myself, but I trust you. Thanks for this critical fix for the release. We still have some time to get field testing.

[TurboGit]

@dtorop : As this was your work, please double check that all is also working fine on your side. TIA.