This is a pretty tricky corner case since it has a lot of build system detail in it. When you say "implementation 'com.example:dependency:x.x.x'", Gradle does a lot of heavy lifting -- executing build scripts to find which repositories to connect to, looking at the project graph to figure out which version to load (it won't always be the one asked for here, since if another dependency depends transitively on a higher version -- that one will be used instead -- unless you've configured a custom version resolution strategy, etc etc etc. Gradle will also download a bunch of artifacts, and in the case of AAR, unzip it into a local folder hierarchy -- and it's this unzipped set of folders that is passed to lint. Lint does not try to replicate all of the above machinery -- it would for sure not match Gradle's implementation over time and would lead to subtle problems.
So instead, you have to configure the model yourself.
There are some built-in tests which do things in this area which you may find helpful.
A fairly straightforward usage is in RestrictToDetectorTest:
Here we register the jar file that would have been found inside the aar file manually to the classpath, and we also register the aar dependency in a gradle test file. Lint's test machinery will associate the two with each other -- so calls which resolve into the jar file found in libs/exploded-aar/
my.group.id/mylib/25.0.0-SNAPSHOT/jars/classes.jar will be understood to correspond to the library my.group.id:25.0.0-SNAPSHOT. (AGP *used* to unpack AAR files in paths like that in the project directory -- some years ago it stopped doing that; they're now in ~/.gradle/ something and the paths do not encode the library coordinates like this anymore, but it's still used here.)
A more complicated but also flexible approach is used in PrivateResourceDetectorTest:
Here you can see we're manually configuring the libraries.