fix(controller): persist LED intensity and white balance calibration

[babo989]

We need to decide on a permanent fix, issue is now solved but fragile.

Consolidate the three duplicated auto-calibration implementations in the dashboard

The LED/white-balance auto-calibration sequence (runInit → runSaturationLoop → runLightnessLoop) exists as three independent copies, all on enabled tabs:

Node	Tab	Size
db1ef284071e60a1	Preview — the "Camera Calibration" modal operators actually use	~707 lines
79bccc0355eb5d87	Acquisition	~1196 lines
97634d7d17fefdeb	Calibration	~371 lines

They have already drifted: the Acquisition copy uses cal_status/cal_step where the others use status/step. There are also two older wizard tabs, "Calibration - Lightness" (c9a6d6f19ff18dda) and "Calibration - Saturation Level" (10c29a65226c0da4), which are enabled but unused.

This duplication is the structural reason calibration bugs keep reopening. #473 reopened four times because each fix landed on one node while its siblings kept the old behaviour, and it was closed only once the same change was made in every copy. #575 had the same shape — persisting on success had to be written three times, and any future change to calibration behaviour will too. Each round the fix looks complete, then reappears as "it works sometimes, depending on which screen you calibrate from."

Two things worth doing, in order:

1. Decide which copies should exist at all. If Acquisition and Calibration are legacy, disabling them removes two thirds of the problem for almost no effort, and the same question applies to the two unused wizard tabs.
2. If more than one must stay, extract the sequence into one shared unit — a subflow or a single function node the templates drive — so the loop logic and its hardware I/O live in exactly one place.

Worth checking for other duplicated logic in the flows at the same time; these two issues suggest it may not be limited to calibration.

[sonnyp]

The hardware controllers (light, bubbler, etc) are designed only to control hardware.
They should not be involved in "business logic". Ideally there are no changes to controller/light to solve this issue.

I see several things to take into consideration:

1. We want calibration to work without a browser
2. We want calibration to happen automatically
3. The code duplication problem you described
4. The quality of the current implementation
5. We have to consider https://github.com/fairscope/PlanktoScope3/issues/327 for later

I think we should discuss this but my thoughts for now:

Calibration should be implemented in the backend, not in the browser. Probably as a new MQTT service.

Dashboard would automatically run calibration before starting an acquisition. Possibly when loading preview too. TBD

Since calibration would happen automatically, I'm not even sure we have anything to save at all.