Duplicate PRs for same dependency in same folder

### Is there an existing issue for this?

- [X] I have searched the existing issues

### Package ecosystem

Gradle

### Package manager version

7.6

### Language version

Java 17 / Kotlin DSL

### Manifest location and content before the Dependabot update

I have three manifests: [`/build.gradle.kts`](https://github.com/spnda/BlockProt/blob/master/build.gradle.kts), [`/common/build.gradle.kts`](https://github.com/spnda/BlockProt/blob/master/common/build.gradle.kts), [`/spigot/build.gradle.kts`](https://github.com/spnda/BlockProt/blob/master/spigot/build.gradle.kts).

### dependabot.yml content

https://github.com/spnda/BlockProt/blob/master/.github/dependabot.yml

### Updated dependency

org.jetbrains:annotations:23.0.0 -> org.jetbrains:annotations:23.1.0

### What you expected to see, versus what you actually saw

Within the dependabot manifest file, I specify each subdirectory for the two manifests that are not in the root directory. I did this, because I can't find any reference to the directory search for a build.gradle{.kts} to look in subdirectories. Dependabot, however, opened two PRs with the same dependency update for a dependency in /common/ (which is not mentioned in the root manifest). One of the PRs title includes "in /common", while the other one doesn't. This could make sense, if we assume that dependabot has changed that it now searches through subdirectories for manifests. However, in the screenshot below you can see another PR was opened for another dependency in /spigot/. For this dependency, there was no second PR, suggesting that it doesn't always search for subdirectories.


### Native package manager behavior

N/A

### Images of the diff or a link to the PR, issue, or logs

The 3 PRs shown in the image before can be found here: https://github.com/spnda/BlockProt/pulls

### Smallest manifest that reproduces the issue

Look at my manifest file linked above, and now create the two manifest files, one in root one in common with a `dependencies { api("org.jetbrains:annotations:23.0.0") }`. That should be enough to spark the bug, however, as I mentioned before, there seems to be cases where this bug does not occur.