21918: ashift: lock when reading buffer geometry from GTK thread

[kofa73]

ashift: read preview geometry under gui_lock

Fixes #21918

The issue:
The preview pipe writes its buffer geometry under gui_lock, but several GUI readers access it without locking. A concurrent update can mix dimensions from different preview runs, affecting the crop outline or automatic crop.
The issue was found by source analysis, @wpferguson then reported high reproduction rate via Lua (he had run into the issue earlier).

The fix:

• Use the dt_iop_gui_enter_critical_section() / dt_iop_gui_leave_critical_section() pair to acquire and release gui_lock.
• Read buffer availability, dimensions, and offsets together under the lock into a new dt_iop_ashift_bufgeom_t struct, then use that local snapshot.
• Apply the same locking to the isflipped readers.

The new helpers release the lock before fitting, drawing, or history updates.

Testing:
no longer reproduces with the Lua script

AI:
Coded by Claude Code; reviewed by Codex.

[ralfbrown]

Looks reasonable on a quick skim. I'll give it a try tomorrow.

[kofa73]

Rebased, no other change

[kofa73]

@ralfbrown : please check if you can find the time.

[kofa73]

Will conflict with #22332 , but I'll clean up whichever is merged later.

[ralfbrown]

Only just got to checking with current master (including 22332) and there are no longer any missing crop updates using a keyboard shortcut for rotation. Haven't had a chance to try applying this PR yet.

There seems to be a slight miscalculation of the "original format" crop box at larger angles, though, as I see a small triangle of black appearing past 4 degrees. That is also present in 5.6.1. It only appears when adjusting rotation while the module is collapsed, and expanding the module and making any adjustment fixes it.