Right, first off, let's deal with "Any code calling the ctor will need updating when new dependencies are added"; To be clear, if you're doing dependency injection and you have any code calling new() on an object with dependencies, you're doing it wrong.
Your DI container should be able to inject all the relevant dependencies, so you don't need to worry about changing the constructor signature, so that argument doesn't really hold.
As for the per-method vs. per-class injection idea, there are two major issues with per-method injection.
One issue is that your class's methods should share dependencies, it's one way to help make sure your classes are separated effectively, if you see a class with a large number of dependencies (probably more than 4-5) then that class is a prime candidate for refactoring into two classes.
The next issue is that in order to "inject" the dependencies, per-method, you'd have to pass them into the method call. This means that you'll have to resolve the dependencies before the method call, so you'll likely end up with a bunch of code like this:
var someDependency = ServiceLocator.Resolve<ISomeDependency>();
var something = classBeingInjected.DoStuff(someDependency);
Now, say you're going to call this method in 10 places around your application: you'll have 10 of these snippets. Next, say you need to add another dependency to DoStuff(): you're going to have to change that snippet 10 times (or wrap it in a method, in which case you're just replicating DI behaviour manually, which is a waste of time).
So, what you've basically done there is made your DI-utilising classes aware of their own DI container, which is a fundamentally bad idea, as it very quickly leads to a clunky design that's difficult to maintain.
Compare that to constructor injection; In constructor injection you're not tied to a particular DI container, and you're never directly responsible for fulfilling the dependencies of your classes, so maintenance is fairly headache-free.
It sounds to me like you're trying to apply IoC to a class containing a bunch of unrelated helper methods, whereas you might be better off splitting the helper class into a number of service classes based on usage, then using the helper to delegate the calls. This still isn't a great approach (helper classed with methods that do anything more complex than just deal with the arguments that are passed to them are generally just badly-written service classes), but it will at least keep your design a little cleaner.
(N.B. I've done the approach you're suggesting before, and it was a very bad idea that I have not repeated since. Turned out I was trying to separate out classes that really didn't need to be separated, and ended up with a set of interfaces where each method call required a near-fixed selection of other interfaces. It was a nightmare to maintain.)