Pluto has no internal state of the notebook unless you work with mutable objects 
That’s pretty subtle, but I guess it makes sense (?)
And allows one to “hack” the notebook a bit by creating constructs that do depend on cell order.
So modifying a Vector for example will persist if the cell defining (and thus “resetting”) the Vector is not re-run explicitly.
In Pluto’s internal dependency graph, running [Cell 7] does not trigger [Cell 4] because that code does not depend on anything from [Cell 7], but the object that was created in [Cell 4] (the parameter vector) can be modified and re-used without problem.
One solution to your problem might be to either use an immutable type for your parameters (not sure if that’s possible with the callback) or making sure that a new parameter vector is generated when you run the solve cell. Something like this perhaps:
make_problem() = ODEProblem(...)
...
sol = solve(make_problem(), ...)
Then every time, the solve cell is re-run, it re-generates a new problem. But make sure to not re-use the same object in the problem again, so this probably still won’t work (there is only one testP object which will be re-used all the time)
make_problem() = ODEProblem(..., testP, ...)
and might need to be this (I’m sure there are nicer ways to write it though, depends on what you need):
make_problem() = ODEProblem(..., [1.], )