The rules are associated with a user authentication event, they run after the initial set of credentials has been provided, so there’s no way to run them for a user that just signed up.
In relation to the (un)availability of client context information within the post registration hook I believe this was a design decision so it’s not available at the moment and unlikely to be. The reasoning was that the user registration process should not be tied to a particular OAuth2 client identifier, in particular, if you need to take different paths depending on the way users enter/signup into your system then you should be explicit and include the necessary information directly associated with the user instead of overloading the client identifier to make that decision.
For example, if you signup users and include sufficient information as user metadata you can then react and customize the steps after the signed up without taking a dependency on a client identifier. In particular, if you have the same service that can be accessed through a web application and mobile application you’ll have different OAuth clients because of different platform requirements but conceptually the users should most likely not be treated differently just because they joined through the web vs mobile (this is just a general example, you could argue that you still have a use case to distinguish web vs mobile, but the point is that if you have that use case, you should still not overload the client identifier as a way to distinguish between them)