Fix stale shot volume carryover

[john-unger]

Summary

Fix intermittent early volumetric stops caused by stale in-memory shot-sample state carrying across shots.

Root cause

The app computes dispensed volume from successive ShotSample packets using a stored SampleTime baseline. That baseline was not being reliably reset for a new shot, and late or out-of-order packets could contaminate the next session while the app stayed connected. This could make the next shot appear nearly finished and trigger Stopping for volume after only a few mL.

This does not look like saved profile corruption. The target volume is still loaded from settings at shot start; the failure mode is stale live state.

Fix

• add an explicit per-shot session reset for espresso and hot water
• reset the ShotSample timing/frame tracking at shot start and again when flow begins
• ignore backward frame-number samples during active flow
• add detailed volume autostop logging, including session, state, substate, frame, current volume, target, and preinfusion volume

Repro

1. Set espresso stop-at-volume to a known target such as 38 mL.
2. Pull a shot to completion and leave the app connected.
3. Without restarting the app, start another espresso shot soon after the previous one ends.
4. Intermittently, the second shot can stop very early with Stopping for volume, sometimes around 5 mL actual output.

Verify fix

1. Repeat the same back-to-back shot sequence without restarting the app.
2. Confirm the second shot no longer stops early due to a carried-over volumetric total.
3. If the issue ever reappears, inspect logs for Starting shot session, reset_shotsample_tracking, Ignoring stale ShotSample, and AUTOSTOP volume reason=volume.
4. Confirm the autostop log shows sane session/frame/current/target values at the moment of stop.

Testing

Manual verification only. No dedicated automated test coverage exists for this Tcl path in the repo.