I keep a little wire next to the charger to tap the positive lead of the shutoff battery to the working battery right next to it in the charger. The chargers already connect the negatives so just a quick tap on the positive brings them back.
I mean what you are describing sounds like an exact match for oscilloscope current probes : https://www.digikey.com/en/articles/understanding-selecting-effectively-using-current-probes They are expensive, but convert AC and DC current to a voltage range reasonable for a scope and do so in an isolated manner. Bandwidth is basically as much as you are willing to pay for.
For current shunts there is the EEVblog uCurrent but it’s not isolated, just a very low burden voltage shunt and amplifier essentially> https://www.eevblog.com/projects/ucurrent/
I know it may seem obvious, but did you check the pins of the BOOT0 switch itself and the nearby capacitor? A stray bit of solder there could cause the switch to appear always held down by shorting either the cap or the switch. It doesn’t appear that the boot0 line goes anywhere other than there and the main microcontroller so the issue is likely there.
I believe the calibration for these grinders looks something like
Either way, the term “calibration” + the name of your grinder should get you a fairly specific run down.
It’s worth noting that if your grinder wasn’t calibrated like this when you got it then your notes will indeed need to be redone. But only once because next time you disassemble for cleaning you start at the known zero point again by going through the simple calibration process.
It’s worth noting that the job of auto-mounting a removable drive is often hidden behind the popular file managers, if you want to do it without one you are probably looking for the “udiskie” application that does this in a more agonistic/generic sense. https://github.com/coldfix/udiskie. With that running in the background to automount, then you can just access the drives from their auto mountpoints in the default location of /run/media/username/drive_label
I suppose that makes sense given that information is encoded as a series of key frames interspersed by 'I-frames" that simply encode the delta to the previous key-frame when using most compressed video algorithms. So cutting in-between key-frames doesn’t really make sense since the I-frame would no longer have anything to reference it’s delta to.