Deserialized JSON fields with `alias` having both the stable and unstable values count as duplicates

This was originally discovered in the EXA repo: https://github.com/element-hq/element-x-android/issues/5081#issuecomment-3131210336

In this case, the `/.well-known/matrix/client` file of the user's homeserver contained:

```json
{
"m.homeserver": {
"base_url": "https://mtrx.oregpreshaz.eu"
},
// First instance of rtc_foci field (unstable)
"org.matrix.msc4143.rtc_foci": [
{
"type": "livekit",
"livekit_service_url": "https://lk.oregpreshaz.eu/livekit/jwt"
}
],
// Second instance of rtc_foci field (stable)
"m.rtc_foci": [
{
"type": "livekit",
"livekit_service_url": "https://lk.oregpreshaz.eu/livekit/jwt"
}
]
}
```

This was added to Ruma [here](https://github.com/ruma/ruma/commit/f73b9bf17cd62c787122385da3f145bc386acc43), with the following format:

```rust
/// A list of the available MatrixRTC foci, ordered by priority.
#[cfg(feature = "unstable-msc4143")]
#[serde(
rename = "org.matrix.msc4143.rtc_foci",
alias = "m.rtc_foci",
default,
skip_serializing_if = "Vec::is_empty"
)]
pub rtc_foci: Vec,
```

And serde fails to deserialize it with the following error:

```
duplicate field `org.matrix.msc4143.rtc_foci` at line 11 column 16
```

It looks like it's taking both the unstable and stable fields as the same one and marking the JSON as invalid because it contains the same field twice. The right behaviour would probably be to take the stable one if present, ignoring the unstable one, I guess this should be done in Ruma since the struct is defined there. I'm opening the issue here to keep track of it, and in case it happens to JSON fields with aliases in some other parts of the SDK.

As far as I can tell, the best workaround until this behaviour is achieved is to keep using the unstable field name, removing the stable one.

Start by reproducing the shown .well-known JSON with both `org.matrix.msc4143.rtc_foci` and `m.rtc_foci`, then inspect the Ruma struct definition and its serde alias handling. Done means deserialization accepts both fields without reporting a duplicate and follows the intended stable-field behavior.

Written by the indexing model from the issue text.