fix(expo-plugins): add the playback service to manifests without <service>

[mziolkowskii]

Summary

Fixes four Expo config plugin bugs: the Android playback service was never added to a manifest without an existing <service> element, the foreground service permissions never reached AndroidManifest.xml, a partial androidExtensions object switched the omitted extension off, and writeToPodfile aborted prebuild on a Podfile it could not anchor into instead of warning. Adds enableAndroidPlaybackService (default true) so an app that uses neither playInBackground nor showNotificationControls can opt out of the service and its permissions. Adds unit tests for the config plugins against parsed native files, and documents on the Expo page what the plugin changes on each platform.

Split out of #5087; the unit test tooling it relies on landed with #5096.

Motivation

• withAndroidNotificationControls pushed onto mainApplication.service with optional chaining, so a manifest with no <service> element yet (the default Expo template) silently got nothing: no VideoPlaybackService, and notification controls did not work. v6 (withNotificationControls) created the array when missing; v7 lost that.
• The plugin added FOREGROUND_SERVICE and FOREGROUND_SERVICE_MEDIA_PLAYBACK to config.android.permissions from inside its manifest mod. expo prebuild registers its built-in mods after the app's plugins and mods run last-registered first, so Expo's own permissions mod has already written the manifest when this mod changes the config: the permissions never reached AndroidManifest.xml. v6 added them through withPermissions at plugin level, which works; this is a regression from v6. With the service now present, an app using showNotificationControls or playInBackground would start a foreground service without the permission it needs (Android 9+, and the mediaPlayback type on Android 14+).
• withAndroidExtensions filled a key missing from a partial androidExtensions object with false, so { useExoplayerHls: false } also disabled DASH, against the documented @default true per key (same in v6).
• mergeContents throws when its anchor is missing instead of reporting didMerge: false, so the warning branch in writeToPodfile was unreachable and prebuild aborted on a Podfile without platform :ios. Note for reviewers: writeToPodfile has no caller in v7 yet (the v6 withCaching/withAds plugins were not ported); the fix keeps the helper correct for when they are, and is covered by tests.

Changes

• withAndroidNotificationControls: create the service array when missing, skip the service when it is already declared, and add the two permissions through AndroidConfig.Permissions.withPermissions at plugin level (as v6 did): it updates config.android.permissions when the plugin is applied, so Expo's permissions mod writes them whatever the mod order, and registers a manifest mod of its own. The warning for a manifest without a main application now names <application> instead of .MainActivity.
• withReactNativeVideo: new enableAndroidPlaybackService option, default true; false skips the service and the permissions.
• withAndroidExtensions: a missing key keeps its default (true).
• writeToPodfile: a missing anchor (ERR_NO_MATCH) is a one-line warning naming the anchor; any other error (an unwritable Podfile) still aborts prebuild.
• Unit tests for withBackgroundAudio, withAndroidPictureInPicture, withAndroidExtensions, withAndroidNotificationControls (asserting the manifest and the config, including with Expo's own permissions mod registered after the plugin, as prebuild does), writeToPodfile and withReactNativeVideo.
• docs/.../with-expo.md: the new option and a "What the plugin changes" section per platform. The agent skill's Android background note pointed at enableBackgroundAudio, which is iOS-only; it now names the service and the new option. enableBackgroundAudio was described as an Android feature; it only edits UIBackgroundModes in Info.plist.
• config/bun-test.d.ts: test.skipIf for the read-only Podfile case, which root would not fail.

Design note: the service and its two permissions have been added to every app that lists the plugin since #4754 (v6 gated it behind enableNotificationControls, which also missed playInBackground). That stays the default: the player starts the service at runtime when playInBackground or showNotificationControls is set, neither is known at prebuild time, and a missing service fails at runtime in a way that is hard to diagnose. Apps that use neither, and want to avoid the Play Console foreground-service declaration, opt out with enableAndroidPlaybackService: false.

Platforms affected

• Android
• iOS
• visionOS
• tvOS / Android TV
• Windows
• Web

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that changes existing behavior)
• Documentation only

Test plan

• bun run test: 223 tests pass (12 new library tests in this PR, the registration test now also covers the opt-out). bun typecheck and bun lint pass.
• Against the plugin source on master, 5 of the new tests fail: the service and permissions on a template manifest, the service on a manifest without <service>, no duplicate service or permissions, the partial androidExtensions default, and a Podfile without an anchor.
• The mod order was also checked outside the unit tests, by running the registered manifest mod chain with @expo/config-plugins 10.1.2 on a template-like manifest with Expo's permissions mod registered after this plugin: on master neither the service nor the permissions end up in the manifest; on this branch both are present exactly once.
• No Maestro flow: the E2E test app uses its own config plugin, not the library's Expo plugins, and was not run through expo prebuild.

Merge order

#5097 rewrites the same line of CONTRIBUTING.md that this PR used to touch, so this PR no longer edits it; either order merges cleanly.

Checklist

• I read the contributing guidelines.
• I added or updated tests that cover this change, or explained under "Test plan" why none apply.
• For a bug fix the E2E suite can exercise, this PR includes a Maestro flow that fails without the fix.
• bun run test, bun lint and bun typecheck pass locally.
• I updated the documentation / README where relevant.
• If this changes how the library is used (API, props, events, behavior), I updated the AI agent skill (skills/react-native-video/) to match.
• This PR is focused on a single concern.
• I tested my changes on at least one platform.

[moskalakamil]

It is true by default, right? otherwise this might be incorrect