Improve dosing logic (now based on predicting time-till-completion); fix parameters initialization bug; various fixes

[death-to-invaders]

Summary of Changes

1. Fixed the bug where parameters entered via the Web UI were saved to flash memory, but the global variables (which drive the dosing logic) were not initialized to these stored values after a reboot. As a result, the UI displayed the previously entered values while the old internal default values were actually being used for dosing.

2. Learned grind delay is now persistently stored in flash memory, whereas previously it was lost after a reboot.

3. Tiny change: The minimum allowed dose is now 6g (which is a perfectly acceptable target for my DF64 grinder, for example)

4. Added an additional safety layer: If the scale stops sending weight updates for more than 2000ms mid-grind (after the first gram is registered), it triggers an emergency abort. Previously, the grinder would blindly run for the full "Max run time (s)" duration in this scenario.

5. The 1.0g startup gate: Discards early weight updates until the scale reaches 1.0g, preventing slow motor startup dynamics from skewing the flow rate calculations. Additionally, rate processing now only occurs if the smartplug relay is switched on.

6. Bypassing filter on startup: The code now bypasses the exponential moving average (EMA) smoothing for the very first weight packet over 1.0g, establishing an instantaneous real-time flow baseline. Previously, there was a zero-bias skew on the first few samples.

7. The main change in dosing logic (Predictive Trajectory): The system now uses the current flow rate to predict exactly how many milliseconds it will take to hit the target weight (minus the mechanical overrun delay).

• Previous Logic: On each weight update, it computed w_pred = w + rate * delay_s and stopped only if it was already above the target.
• New Logic: On each weight update, it computes the exact time deadline when w_pred is expected to reach the target dose, and schedules the relay=off command for that precise moment in the future.
• Example: If the grind rate is 2.0g/s, the target is 18.0g, the delay is 500ms, and a new weight update reads 16.8g (meaning stopping immediately would yield 16.8g + 2.0g/s * 0.5s = 17.8g < 18g), the old logic would blindly command "continue grinding until the next weight update." If a high-latency scale sends the next packet late at 17.5g (which does sometimes happen with this $12 scale), the grinder overshoots by 0.5g. The new algorithm computes that it will take exactly 100ms to hit the target weight — (18g - 17.8g) / 2.0g/s = 100ms — and stops after another 100ms instead of waiting around for the next scale update.