`denoiseprofile`: variance readout written on a pipe thread, read on the GTK thread, no lock

Summary

Three floats in gui_data are written from a pixelpipe thread and read from a GTK draw
callback, with no critical section on either side.

The two sides

Writer, process_variance() (1890), called from process() (2615), so a pipe thread:

  g->variance_R = var[0];    /* 1946 */
  g->variance_G = var[1];    /* 1947 */
  g->variance_B = var[2];    /* 1948 */

No dt_iop_gui_enter_critical_section() anywhere in the function. The function does
guard on g == NULL and returns early on the preview pipe (1903-1907), so the writes
happen on the full and export-style pipes when a GUI exists.

Reader, denoiseprofile_draw_variance() (3178), a GTK draw callback:

  if(!dt_isnan(g->variance_R))                    /* 3185 */
    gchar *str = g_strdup_printf("%.2f", g->variance_R);   /* 3187 */

and likewise for _G (3193, 3195) and _B (3201, 3203). Also unlocked.

Impact

A torn or stale read of a float, and a NaN check that can pass on the check and then
read a different value on the use — the reader loads each field twice (3185 then 3187).
The displayed number can be wrong or the branch inconsistent with the value printed.

Low severity: the consequence is a wrong readout, not a crash. It is listed because it
is the shape the documentation warns about, in a module that otherwise looks careful.

Suggested fix

Snapshot the three values into locals inside one critical section on the reading side,
and write them inside one on the writing side. They are plain scalars, so the span in
which they must stay valid ends at the load; a short section is sufficient and correct.

Locate the denoiseprofile module and inspect process_variance() called from process(), alongside the denoiseprofile_draw_variance() GTK callback. Trace the existing critical-section conventions, then verify that the variance values are consistently synchronized and that the readout remains correct without check/use races.