Your correction system is effectively a "PID" controller with a "P" term. These will always be "springy."

There are two things to do to make it better.

First, make sure that the very simplest case with zero loss results in zero correction. Make it so that the player pushes the box at time T with some known velocity, but doesn't push at times T-1 or T+1. Then make sure that this action can make it through the system without correction. If you get corrections, it means either that your communication system corrupts data, or that the time stamps aren't correctly used. (That is: The player needs to push the box "ahead" of the server to arrive in time.)

Once that works, you have to make a trade-off between "degree of acceptable difference" versus "degree of snappiness in corrections" versus "degree of sloppiness in movement." There is no 100% correct solution here. If nobody else has pushed the block in the intermediate time, you might even choose to let the client's position be preferred, and correct the server (within reason.)

I would nominally assume that a reasonable system would correct the velocity by exactly the difference, and correct the position by exactly the difference, for each step where there is a difference, but then subtract out that difference until you reach the step you corrected at.

E g, if you correct based on a delta at time (t-15) by dV and dP, then you should remove dV and dP from the calculated corrections for times (t-14) ... (t-1) but should then assume that you're in sync again at (t+0). This means that you need a second array, into which you accumulate correction turns, so you know not to re-correct for the (t-14) discrepancy if you already corrected for the (t-15) one.