Thanks a lot for your contribution! 😃 The code looks quite clean and works 🙂
To save some time I simply adjusted the code directly and created two commits from it.

Here are the bigger things I changed:

• I renamed JavaCodeUnit.getAllTypesInvolvedInSignature() to simply JavaCodeUnit.getAllInvolvedRawTypes(), because IMHO there is no other way how the "raw types involved in a method" could be understood anyway.
  Instead I added some more detailed Javadoc to explain what exactly it means
• I pulled up JavaCodeUnit.getAllInvolvedRawTypes() to JavaMember.getAllInvolvedRawTypes(), because I think it also makes sense for JavaField (there the signature is basically simply the type) and then it's more unified
• I made JavaClass.getAllInvolvedRawTypes() return the base component type instead of the class itself, because if the JavaClass represents an array I think we are interested in the component type and not the array type.
  This method is mainly about finding dependencies and the array type is usually not the dependency we're interested in, but the component type. I might be wrong there, maybe it's array type and component type, but I'd wait for
  a concrete issue before adjusting it 😁

But I'm gonna try to give you some feedback on the stuff I noticed so you can hopefully also take some stuff away 🙂

First thing I noticed was the commit structure. For ArchUnit we try to create self-contained logical units.
At least to be ready to merge, the history shouldn't look like "this is what I did in which order", but "these are logical, cohesive and self-contained steps to reach the goal".
These steps should be as small as possible, but still contain a logical unit. For example, a commit "add tests" i.g. doesn't make any sense IMHO.
Because it means the commits before were incomplete. For me the tests are an inseparable requirement for the implementation.
You should be able to check out any commit and the code base in this state should be complete, reasonable and fully tested.

Another thing I noticed was that Javadoc was missing. We don't create Javadoc in a cargo cult way, but every non-trivial method should get it.
And "involved raw types" isn't self-explanatory enough from my point of view to be understood i.g. without any Javadoc.
BTW: Public methods also need an explicit annotation @PublicAPI or the tests will fail 😉

Regarding the tests, there are a lot of custom assertions that make your life simpler. We never use JUnit assertEquals, but only AssertJ, since it's nicer to read and offers autocomplete. But for all domain objects where we have recurring assertions we have custom matchers, e.g. assertThatTypes(..) which then directly allows to assert class objects.
I also thought that in some places the test cases could have been a little more complex, so I adjusted this.
You could also try test driven development for these nice self-contained cases, because for some code I saw that test cases were missing.
E.g. you implemented stuff in JavaGenericArrayType, but I didn't see any test with a generic array. If you would do this test driven, then such a thing couldn't happen 🤷‍♂️
Also, in tests you don't need to import every single type involved, because ArchUnit has an automatic resolution process that will import transitive stuff as needed. So it's always worth a shot if importClass(Single.class) is maybe already good enough for the test case.

Last but not least I saw quite some unrelated code reformatting. IMHO you shouldn't touch unrelated code like this, definitely not in the same commit as "real" changes, cause it just makes the review harder (and reasoning about the change later on as well).
If you think some formatting is suboptimal we can discuss it and potentially adjust it, but it should at least be a completely separate commit then with a message explicitly describing that this is a pure formatting change.
Nevertheless, I also saw that a fresh import of the IntelliJ code style meanwhile sets hard wrap by default to 150 chars 🙈
This was different in earlier times, so I adjusted the code formatter for IntelliJ in a pre-commit to fix the hard wrap to something so big that we effectively just decide about the line breaks.
Not sure if this is i.g. the best thing, or if we should have a more restrictive hard wrap, but so far I also don't remember this to caues any problems 🤷‍♂️

BTW: We also don't use any branch prefix convention 😁 E.g. in the PR title...

Wow! thanks a lot for this extensive feedback 😄🙏🙏