Adding any second AndroidLibrary/AndroidMavenLibrary-based content duplicates existing Firebase/GooglePlayServices namespaces (XAAMM0000)

### Android framework version

net10.0-android

### Affected platform version

36.1.69

### Description

When a MAUI Android app project already consuming Firebase (Plugin.Firebase.CloudMessaging/Plugin.Firebase.Core, which transitively bring in Xamarin.Firebase.* and Xamarin.GooglePlayServices.* packages) adds any additional native Android library content via (or its wrapper), the build fails with XAAMM0000/AMM0000 reporting that Firebase/GooglePlayServices namespaces are used in multiple modules.

Byte-for-byte comparison of the intermediate extracted .aar files under obj/.../lp/*/jl/ confirms these are the exact same physical library content appearing twice in the merged library list, not a version conflict — `dotnet list package --include-transitive` resolves exactly one version of every package involved, both with and without the added library.

Environment:
- dotnet --version: 10.0.302
- Android workload: 36.1.69/10.0.100 (installed via VS 18.8.12009.203) — confirmed latest stable Microsoft.Android.Sdk.Windows on NuGet at time of writing (only preview/RC builds are newer)
- Existing app packages: Plugin.Firebase.Core 4.2.0, Plugin.Firebase.CloudMessaging 4.0.1 (pull in Xamarin.Firebase.Messaging 124.0.0.2, Xamarin.GooglePlayServices.Basement/Base/CloudMessaging/Stats, etc.)
- Target: net10.0-android36.0

Expected behavior: adding a second /-based dependency (with no actual content overlap) should not cause pre-existing, already-correctly-resolved libraries to be processed twice during manifest merge.

### Steps to Reproduce

When a MAUI Android app project already consuming Firebase (Plugin.Firebase.CloudMessaging/Plugin.Firebase.Core, which transitively bring in Xamarin.Firebase.* and Xamarin.GooglePlayServices.* packages) adds any additional native Android library content via (or its wrapper), the build fails with XAAMM0000/AMM0000 reporting that Firebase/GooglePlayServices namespaces are used in multiple modules.

Byte-for-byte comparison of the intermediate extracted .aar files under obj/.../lp/*/jl/ confirms these are the exact same physical library content appearing twice in the merged library list, not a version conflict — `dotnet list package --include-transitive` resolves exactly one version of every package involved, both with and without the added library.

Environment:
- dotnet --version: 10.0.302
- Android workload: 36.1.69/10.0.100 (installed via VS 18.8.12009.203) — confirmed latest stable Microsoft.Android.Sdk.Windows on NuGet at time of writing (only preview/RC builds are newer)
- Existing app packages: Plugin.Firebase.Core 4.2.0, Plugin.Firebase.CloudMessaging 4.0.1 (pull in Xamarin.Firebase.Messaging 124.0.0.2, Xamarin.GooglePlayServices.Basement/Base/CloudMessaging/Stats, etc.)
- Target: net10.0-android36.0

Expected behavior: adding a second /-based dependency (with no actual content overlap) should not cause pre-existing, already-correctly-resolved libraries to be processed twice during manifest merge.

### Did you find any workaround?

_No response_

### Relevant log output

```shell
When a MAUI Android app project already consuming Firebase (Plugin.Firebase.CloudMessaging/Plugin.Firebase.Core, which transitively bring in Xamarin.Firebase.* and Xamarin.GooglePlayServices.* packages) adds any additional native Android library content via (or its wrapper), the build fails with XAAMM0000/AMM0000 reporting that Firebase/GooglePlayServices namespaces are used in multiple modules.

Byte-for-byte comparison of the intermediate extracted .aar files under obj/.../lp/*/jl/ confirms these are the exact same physical library content appearing twice in the merged library list, not a version conflict — `dotnet list package --include-transitive` resolves exactly one version of every package involved, both with and without the added library.

Environment:
- dotnet --version: 10.0.302
- Android workload: 36.1.69/10.0.100 (installed via VS 18.8.12009.203) — confirmed latest stable Microsoft.Android.Sdk.Windows on NuGet at time of writing (only preview/RC builds are newer)
- Existing app packages: Plugin.Firebase.Core 4.2.0, Plugin.Firebase.CloudMessaging 4.0.1 (pull in Xamarin.Firebase.Messaging 124.0.0.2, Xamarin.GooglePlayServices.Basement/Base/CloudMessaging/Stats, etc.)
- Target: net10.0-android36.0

Expected behavior: adding a second /-based dependency (with no actual content overlap) should not cause pre-existing, already-correctly-resolved libraries to be processed twice during manifest merge.
```

Reproduce the failure for net10.0-android with Firebase packages and a second AndroidLibrary or AndroidMavenLibrary-based dependency. Inspect the duplicated extracted AARs under obj/.../lp/*/jl/ and compare dotnet list package --include-transitive results. Done means the additional native library no longer causes duplicate Firebase or GooglePlayServices namespaces and XAAMM0000/AMM0000.

Written by the indexing model from the issue text.