The benefit of your current design is that the observers can control WHEN they are observing. When an observer wants to start observing it registers (or subscribes if you like) with the observed object (subject) by calling a register method and passing a reference to itself.
You're worried about this creating an unneeded dependency. The only dependency here is on the subject interface that ensures their are register and unregister methods to call. Oh, and you need a reference to the subject. The observer doesn't even need to know the subjects type.
So it isn't so much a question of dependency. It's a question of whether you want your observers to be responsible for deciding when they observe.
If you don't want your observers to be responsible for deciding when they observe you need some 3rd thing that will take on that responsibility.
It is possible to provide the subject with it's list of observers when building the object graph. You'll either need to call a setter on the subject over and over, call a constructor that takes a variable number of args, or pass it a collection of observers.
If your DI container can do any of those then it can be your "some 3rd thing". If not you might need to write construction code that acts as the "some 3rd thing".