EX should not set `power_level_content_override` on room creation

## Context

Currently, Element X (Android v25.09.2 and iOS v25.09.12) is hardcoded to include
```json
"power_level_content_override": {
"events": {
"org.matrix.msc3401.call.member": 0
}
}
```
when creating a room (`POST /_matrix/client/v3/createRoom`). This happens regardless of choosing the "Private room" or "Public room" preset.

I understand that the motivation behind this behavior is to make it easier for users to join calls:
- https://github.com/element-hq/element-meta/issues/2230
- https://github.com/element-hq/element-x-android/pull/1927
- https://github.com/element-hq/element-x-ios/pull/2187

However, **this behavior directly contradicts the long-established behavior of other clients**, including Element Web and the legacy Element mobile apps, which respect the homeserver's default power level content instead of overriding it.

## The Problem

**This becomes a serious UX-breaking issue** when the homeserver's configured default power level content deviates from the default configuration programmed into Synapse.

Both examples of `default_power_level_content_override` given in [Synapse's documentation](https://element-hq.github.io/synapse/v1.139/usage/configuration/config_documentation.html#default_power_level_content_override) are broken whenever a room is created by Element X. Here is a third example:

> ### Synapse configuration:
>
> ```yaml
> default_power_level_content_override:
> public_chat:
> events:
> m.reaction: 0
> m.room.redaction: 0
> events_default: 50
> ```
>
> The expectation is that public rooms, by default, will allow unprivileged users (PL 0) to send and remove reactions but not send messages or any other event type.
>
> ### Resultant `m.room.power_levels` when a public room is created with Element Web:
>
> ```json
> {
> "users_default": 0,
> "events": {
> "m.reaction": 0,
> "m.room.redaction": 0
> },
> "events_default": 50,
> "state_default": 50,
> (etc)
> }
> ```
>
> This room allows PL 0 to send and remove reactions but not any other event type, as expected. This is correct.
>
> ### Resultant `m.room.power_levels` when a public room is created with Element X:
>
> ```json
> {
> "users_default": 0,
> "events": {
> "org.matrix.msc3401.call.member": 0
> },
> "events_default": 50,
> "state_default": 50,
> (etc)
> }
> ```
>
> This room correctly prevents PL 0 from sending messages and other event types, but it **does not allow PL 0 to send and remove reactions**. This is incorrect.

## Suggested Fix

The use of `power_level_content_override` in Element X should be reverted. A general-purpose Matrix client like Element X, that is used in numerous different environments with different expectations and configurations, should probably _never_ use `power_level_content_override`.

A much cleaner way to resolve the original motivation would be to change the default power level content within Synapse and other homeserver implementations. As things stand, with all default configurations, a room created today on Element Web would _still_ not allow users to join MSC3401 calls without manual intervention.

Start with the room-creation behavior described for Element X on Android and iOS, and review the referenced Android and iOS pull requests alongside POST /_matrix/client/v3/createRoom. Done means Element X no longer sends the power_level_content_override field, allowing homeserver defaults such as default_power_level_content_override to determine the resulting room power levels.

Written by the indexing model from the issue text.