An under-appreciated fact about the A* pathfinding algorithm is that it's not restricted to finding shortest paths in the spatial sense. It finds the shortest sequence of moves to solve any problem that can be expressed as walk on a graph.
And your problem is a walk on a graph.
Each node of the graph is one particular assignment of n x m numbers to the cells in the grid.
Each node has an edge leading to every other node that can be formed by subtracting 1 from one of its cells and adding 1 to a neighbouring cell.
So now you have a starting node (your "initial" state), a goal node (your "resolved" state), and a procedure to enumerate the nodes reachable from the current node (for each cell, subtract 1 from its value and try adding it to each of the cell's neighbours in turn).
All we need to add to use A* is a heuristic, to estimate how many swaps remain to be done. A good heuristic lets us focus our search on the most promising parts of the graph, and save time by not exploring "bad" moves.
We could just use a heuristic of 0 - that's admissible (it never over-estimates the remaining work), but it doesn't help us distinguish promising moves from useless / harmful ones. With this, A* effectively falls back to Djikstra's algorithm, exploring equally in all directions until it happens across the solution.
But we can do better. Iterate over all your cells, and for each one take the absolute value of the difference between its current value and its resolved value. Sum up those absolute differences to get the total amount of value we need to shunt around, and divide by 2 (since each step could potentially move 2 cells closer to their correct value).
This is also an admissible estimate (never over-estimates), and while it can under-estimate the distance, it's a lot more accurate - it gives the correct move count for all three of your examples, for instance.
You could probably do even better than this, by factoring in some spatial information. Like if a cell is 1 above its resolved value, and the closest cell below its own resolved value is 5 units away, you know you need to do at least 5 swaps to transport the excess to a suitable sink. But this is more complicated to compute, so there's a trade-off between choosing an accurate heuristic that lets you evaluate a minimal number of nodes, and choosing a cheap heuristic that you can evaluate quickly, so evaluating a few more nodes isn't a problem. Especially for small problem sizes, the options above might be all you need.
Once A* has found found its way to a solution, guided by this heuristic, it will report back the number of steps on the path from the initial state to the goal. This count is guaranteed to be the smallest possible, as long as you use an admissible heuristic.