Feature/ios chromecast phase1 spine

[AymanL]

Wires the Google Cast iOS Sender SDK into the project as Phase 1 (out of 5, already-made, branches) of the Chromecast feature. No Cast UI is exposed in this PR, nothing visible to users. The goal is to prove the dependency integrates cleanly, the SDK initializes correctly at launch, and the receiver identity contract is tested and pinned.

All phases code has been tested and is building and running on my iPhone, starting from phase 3 they are all able to cast videos. If something is not working on your machine, I'll be more than happy to take a look at any specific use case I might've missed.

Explicit choices

• The stable ID (F007D354) is used for all non-debug builds, consistent with jellyfin-web's default. The unstable ID (6F511C87) is declared in the same enum for future use when testing unreleased receiver changes, but is not referenced in any active code path in this PR.

• JellyfinCastReceiverID contains magic strings that must match Google's Cast application registry and jellyfin-web's values exactly. If they drift, the app builds and runs silently but Cast fails on device with no compiler or runtime signal. The tests act as a human-review tripwire: stableReceiverIDMatchesKnownValue breaks loudly if either ID changes, forcing a conscious check against upstream before updating.

• Phase 1 is infrastructure only. A reviewer running a release-equivalent build should see no Cast-related screens. UI (device picker, Cast button) comes in Phase 2 after the manager-proxy spine is exercised.

Future phases' PRs (on my fork atm, will open them one by one in the official repo as we go):

• Phase 2: Cast button & session coordinator
• Phase 3: Jellyfin PlayNow and phone to TV transport
• Phase 4: Add receiver sync
• Phase 5: encoder/inbound coverage for PlayNow and playbackstart

[JPKribs]

Please don't include custom bundle identifier changes.

[LePips]

Thank you for the consideration of breaking these up into PRs, but this is probably something I would request at least a big chunk of it at once for architectural input. I've taken a look at your own PRs for the implementation and we would have to go in a very different direction.

For some guidance:

• This should be implemented as a MediaPlayerProxy, like a ChromeCastMediaPlayerProxy. This wouldn't require any specific cast considerations in MediaPlayerManager and elsewhere throughout the app.
• The video player should have work to have it be given a proxy and be able to have the proxy be able to be changed

Initially, let's have this as an experimental feature. I haven't even gotten into video player overlay changes or the ability to launch straight into a cast from elsewhere throughout the app.