Enable detector-view pixel weighting by default

[SimonHeybrock]

Stacked on #1369 (which is stacked on #1358 and #1360).

Detector views histogram detector pixels onto an image grid. With pixel weighting enabled, each image pixel is divided by the number of detector pixels that map to it, so the image shows counts per detector pixel. This PR turns weighting on by default.

Why. In geometric projections (xy-plane, cylinder) the number of detector pixels per image pixel varies across the image. Unweighted, image pixels hit by more detector pixels look brighter and gaps look dark, so the image shows pixel density as well as count rate. With weighting, image pixels that no detector pixel maps to are 0/0 = NaN and render blank instead of as zero counts. In logical views every image pixel has the same number of detector pixels: weighting is a no-op (one detector pixel per image pixel) or divides the whole image by a constant (views with reduction_dim). Weighted images are also consistent with the "Per Detector Pixel" ROI plot option of #1369: for a uniform count rate, an ROI's counts per detector pixel equal the weighted image values inside it.

Regression test. Enabling weighting on a logical view used to fail because LogicalProjector.compute_weights created weights with unit None. The fix is in #1360. This PR adds a test that runs a logical view with and without reduction_dim, with weighting on and off.

Descriptions. The setting's title, description, and field tooltips are rewritten to say what weighting does, where it matters, and how empty image pixels render. The image output description notes that weighted counts are per detector pixel.

Single source of the default. create_base_workflow no longer sets UsePixelWeighting = False; the factory always sets it from params.pixel_weighting.enabled, so the params model holds the only default.

Consequences.

• The dashboard saves the full params of a workflow when it is started or stopped, including pixel_weighting.enabled: false. Workflows started at least once before this change keep weighting off until a user enables it or the saved config is cleared. Only workflows without a saved config pick up the new default.
• Values published to NICOS change for jobs started with weighting on: DREAM, LOKI and MAGIC projection images become counts per detector pixel and carry NaN in image pixels without detector pixels; BEER bank_view and TBL ngem_detector_view images are divided by a constant (the number of detector pixels summed into each image pixel). Other logical-view image devices are unchanged, and so are all total-count devices, which sum the histogram rather than the image.
• The image unit stays counts, so the colorbar does not show that values are per detector pixel. scipp has no unit for a detector pixel, and the image plotter cannot tell whether a job weighted its image. Follow-up: Weighted detector images are labelled counts instead of counts per detector pixel #1371.
• In geometric views, the "latest update" image shows speckle at module edges, up to 5x the true per-pixel value: a single batch uses one position-noise replica, but the weights are averaged over all replicas. Cumulative images average this out. The mismatch predates this PR; the new default makes it visible. Follow-up: Weighted latest-update images divide by replica-averaged pixel weights #1370.
• Tests that check "image sum == number of events" now disable weighting explicitly (or use nansum), since that identity holds only for unweighted images.

Test plan

• Dashboard: open the configuration of a detector view and check that the Pixel Weighting tab text and the Enabled/Method tooltips read correctly.
• Dashboard (fake backend or live): start a geometric projection (e.g. DREAM mantle or LOKI) with default parameters and check that gaps render blank and the image shows no pixel-density pattern.
• Start a logical view with reduction_dim (e.g. TBL ngem or DREAM wire view) with weighting on and check that it runs and values are counts per detector pixel.

🤖 Generated with Claude Code