`dotnet publish` + $(RuntimeIdentifiers) in .csproj supersedes `-r RID` on command line

### Android framework version

net9.0-android, net10.0-android (Preview)

### Affected platform version

.NET 10 Preview 7

### Description

(Possible dupe or alternative statement of #10384.)

Story time!

Create a new .NET for Android project:

```dotnetcli
dotnet new android -n android-rids
```

Publish it:

```dotnetcli
cd android-rids
dotnet publish -c Release
```

and the resulting `.apk` contains native bits for both of the default `$(RuntimeIdentifiers)` within dotnet/android:

```sh
% unzip -l bin/Release/net10.0-android/*-Signed.apk | grep libmonodroid
1508048 01-01-1981 01:01 lib/arm64-v8a/libmonodroid.so
1498184 01-01-1981 01:01 lib/x86_64/libmonodroid.so
```

Furthermore, we can build for a *single* RID:

```dotnetcli
rm -Rf bin obj
dotnet publish -c Release -r android-arm64
```

And the resulting `.apk` contains native libs for only the specified RID:

```sh
% unzip -l bin/Release/net10.0-android/android-arm64/*-Signed.apk | grep libmonodroid
1508048 01-01-1981 01:01 lib/arm64-v8a/libmonodroid.so
```

Everything up to here makes sense.

---

Next, update the `.csproj` so that it has its own `$(RuntimeIdentifiers)` (plural) value:

```diff
diff --git a/android-rids.csproj b/android-rids.csproj
index ac732b8..91def5d 100644
--- a/android-rids.csproj
+++ b/android-rids.csproj
@@ -9,10 +9,11 @@
com.companyname.android_rids
1
1.0
+ android-arm64;android-x64^

full

```

And repeat the exercise above, building for a single RID:

```dotnetcli
rm -Rf bin obj
dotnet publish -c Release -r android-arm64
```

And the resulting `.apk` contains native libs for…*all* the RIDs?

```sh
% unzip -l bin/Release/net10.0-android/android-arm64/com.companyname.android_rids-Signed.apk | grep libmonodroid
1508048 01-01-1981 01:01 lib/arm64-v8a/libmonodroid.so
1498184 01-01-1981 01:01 lib/x86_64/libmonodroid.so
```

(Also note the path in the above: `bin/Release/net10.0-android/android-arm64`. At least the `-r android-arm64` value was meaningful *somewhere*…)

I *suspect* that this may be what #10384 was getting at: they're building their `.apk` for one RID, but the `.apk` contains *multiple* RIDs.

I believe this is a bug: the `.csproj` containing a `$(RuntimeIdentifiers)` value should not "supersede" the `-r RID` value on the `dotnet publish` command line. Adding `$(RuntimeIdentifiers)` to the `.csproj` shouldn't change behavior vs. what the default behavior is.

---

**But what about…console apps?**

Consistency is handy, and it sure looks likes `dotnet publish` on a console app behaves as one would expect: i.e., adding `$(RuntimeIdentifiers)` to the `.csproj` does *not* cause *all* of them to be created:

```dotnetcli
dotnet new console -n console-rids
cd console-rids
```

Set `$(RuntimeIdentifiers)`:

```diff
diff --git a/console-rids.csproj b/console-rids.csproj
index 8474795..690a639 100644
--- a/console-rids.csproj
+++ b/console-rids.csproj
@@ -6,6 +6,7 @@
console_rids
enable
enable
+ osx-arm64;osx-x64



```

Publish without a RID:

```dotnetcli
dotnet publish -c Release
```

Here things actually break down; only one RID is created, and it's the RID for my local OS (osx-x64).

However, I can still specify the other RID:

```dotnetcli
rm -Rf bin obj
dotnet publish -c Release -r osx-arm64
```

and the resulting binary is for *not* my local OS:

```sh
% file bin/Release/net10.0/osx-arm64/publish/console-rids
bin/Release/net10.0/osx-arm64/publish/console-rids: Mach-O 64-bit executable arm64
```

Additionally, no `bin/Release/net10.0/osx-x64` directory is created.

### Steps to Reproduce

-

### Did you find any workaround?

_No response_

### Relevant log output

```shell

```