[BUG] MediaElement steals audio session on iOS when configured to play silently

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Did you read the "Reporting a bug" section on Contributing file?

- [x] I have read the "Reporting a bug" section on Contributing file: https://github.com/CommunityToolkit/Maui/blob/main/CONTRIBUTING.md#reporting-a-bug

### Current Behavior

When a `MediaElement` is configured to silently autoplay video (`ShouldAutoPlay="True"`, `ShouldMute="True"`), the underlying iOS `AVPlayer` still activates the shared `AVAudioSession` with `CategoryPlayback`. This causes the iOS audio session to be stolen, even though the `MediaElement` produces no audible output.

The effect is that any audio playing from another source (e.g. Spotify, Apple Music, a podcast app) is interrupted or paused whenever the muted `MediaElement` begins playback.

This is a platform-level side effect of how `AVAudioSession` works on iOS. Setting the category to `Playback` and activating the session is a way to indicate that my app intends to be the primary audio source.

### Expected Behavior

When a `MediaElement` is configured to play silently (muted or zero volume), it should not interrupt or claim exclusive ownership of the iOS audio session. Ideally, the `MediaElement` (or its platform view) should either:

1. Use `AVAudioSessionCategory.Ambient` (or `Playback` with the `.MixWithOthers` option) when the media is muted, so that other audio sources are not interrupted.
2. Expose a configurable property (e.g. `AudioSessionCategory` or `AudioMixBehavior`) that allows the developer to control the `AVAudioSession` category used by each `MediaElement` instance.
3. Provide a way to pass audio session configuration through `ToPlatformView` or via the `MauiMediaElement` constructor on iOS/macOS, so that developers can influence the `AVAudioSession` setup at the platform level.

Option 3 would be the most flexible, as it would allow developers to handle their own use-case-specific audio session management without the toolkit needing to anticipate every scenario.

### Steps To Reproduce

1. Create a .NET MAUI application targeting iOS.
2. Add a single `MediaElement` to a page, configured to autoplay muted:

```xml

```

3. Before opening the app, start playing audio from another app (e.g. Spotify or Apple Music).
4. Launch the MAUI app on an iOS device or simulator.
5. Observe that the background audio is interrupted/paused as the muted `MediaElement` begins autoplay.

There's a reproduction project repo linked below too.

### Link to public reproduction project repository

https://github.com/Joeb454/maui-media-element-repro

### Environment

```markdown
- **CommunityToolkit.Maui.MediaElement**: 8.0.0
- **OS**: iOS 18.x (also reproducible on earlier iOS versions)
- **.NET MAUI**: 10.x
```

### Anything else?

The root of the issue appears to be in `MediaManager.macios.cs`, where the `AVAudioSession` is configured during player setup. Currently there is no mechanism to influence the audio session category from the `MediaElement` API or to pass configuration through to the platform view.

Start by reading MediaManager.macios.cs, where the issue identifies AVAudioSession setup during player initialization, and use the linked maui-media-element-repro project to reproduce the muted autoplay behavior. Compare the available handling options in the issue and verify that a muted or zero-volume MediaElement no longer interrupts background audio on iOS, or that its audio-session behavior can be configured.

Written by the indexing model from the issue text.