Thanks Kleintein for the heads up.
Indeed, without absolute knowledge of what the firmware is doing, it's a pain to troubleshoot the A/D, because nothing can be taken for granted (since the uP is actually entitled to do whatever the programmer felt like doing).
There's just so much that we can deduce by just looking at the pure sequential logic (the few gates, counters and flip-flops that are used in the charge-balance section of the A/D), that works on its own independently from the uP.
And the Theory of Operation described in the manual is very, very superficial.
Since the signals repeat so slowly, to me at least who have an analog oscilloscope with only three channels (even though with storage CRT), it was hard to catch the spikes during the MUX transitions, but they're there! They raise all the way up to 1.5 ish volts, and the big part of them last for some 200us.
But the evil is in the lingering... as the discharge is exponential, after the greater part of the spike went away, the reminiscent charge can take quite long to dissipate and it's impossible to see it well in the oscilloscope because it's Hi-Z and 60Hz pick-up gets in the way of a cleaner reading (and adding a capacitor to filter out the signal is not an option).
And I was only able to reach any conclusion because in my scope (a Tek 7623A), I have a 7A13 (differential comparator), which allowed me to increase the gain all the way up to 1mV/div and use the infinity impedance input (whch is quite leaky in comparison to the 197's input btw).
But further down the rabbit hole, I`m finally coming to a conclusion about what was annoying me the most, which is the quite high noise of 2 digits (+ or = 40ish counts), even shorting the inputs.
I knew the charge injection from the MUX was a "bitch", but I also knew it could not be the cause for that with shorted inputs.
And as this +-40 counts are irrespective of range, I knew it could only be from the A/D itself, so I went down that road and started investigating the A/D operation.
I was looking at the output of the integrator and finding it very weird that I could never see it goes through the "Single Slope" stage of the conversion.
I could see it doing the multiple charge-balance up/down ramps, but it would never go to zero volts... instead it was going - every so often - to saturation of the A/D integrator op-amp (all the way to +V).
At first I wasn't sure if that was some artifact from the way how the uP controls the process... but as I dug a little bit more into the A/D workings, I can now tell for sure there's something wrong with the A/D.
It seems it's not performing (at all) the last stage of "Single Slope" conversion...It's obtaining whatever readings it's getting with only the result of the first stage of the conversion (i.e. the "charge-balance" stage).
I never thought it would be even possible to have such a "gross" malfunction and the meter still be able to operate... but that, I think, it's thanks to the "software calibration" feature and the fact the calibration constants can compensate for a very wrong reading.
And no, I never "reset" the calibration constants because I was in the hopes I could still get away with having to calibrate the meter again.

Right now I have unsoldered all the analog part of the A/D circuitry because I wanted to be sure there was nothing hiding under the components (maybe some contamination, or solder flux, etc...), and also be able to confirm out-of-circuit, if all the components are healthy.
But as soon as I put everytihng back again, I`m sure I`ll be able to monitor the relevant control signals and understand why the A/D is not performing the last "Single Slope" conversion stage.
I`ll keep you all posted. I think I`m very close to solve this problem (which I think is exactly the same as what @Trobbins have).