Speculative answer: This may have less to do with Proguard and more to do with some of the optimizations made specifically in Dagger 2.12.
Because you're running Dagger on the library you're created, and then consuming that library from a different Dagger app, Dagger gets two chances to run: First for the library, which creates your ReportingService_MembersInjector, and then a second which presumably consumes that same ReportingService. Between those steps, Proguard can effectively do whatever it wants to classes that you haven't marked with -keep and related switches. My hunch is that Dagger needed to keep your injectA method as of 2.5, but the 2.12 optimizations no longer need you to keep that method, so Proguard eliminates it.
In your Android app that consumes the library, Dagger detects a class named ReportingService_MembersInjector, so it doesn't create another copy, and incorrectly assuming it contains all of the methods that it would generate.
I think the root of the problem is that your library exposes an @Inject-annotated class that your outer (app) Dagger graph is evidently consuming directly, and then you are also keeping the Factory and MembersInjector classes that Dagger provides adjacent to it. Even if you were to properly -keep your generated MembersInjector, Provider, and Factory classes, you might experience version differences between the inner obfuscated library and the outer copy of Dagger that would make for different sorts of trouble. Instead, provide a factory or other official way of creating your library class from the outside of the library, so there's no reason that the two Dagger runs can interfere with one another.
