fix(core): stop config mutation and propagate native errors reliably

[mziolkowskii]

Summary

Fixes four bugs in the library's JS core that the new unit tests surfaced: createSource mutating the caller's config, errors swallowed after the last onError listener is removed, promises that hang or reject with undefined on a native rejection, and a second release() inside the grace window re-running teardown. Adds the unit tests that cover them.

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

Motivation

• createSourceFromVideoConfig wrote its defaults (initializeOnCreation: true, the platform DRM type, normalized externalSubtitles) back into the object it was given. useVideoPlayer keys the player on JSON.stringify(source), so a config the caller keeps around (a module constant, a useMemo/useState value) produced a different key on the next render and useManagedInstance destroyed and recreated the player.
• triggerJSEvent returned true for an event whose last listener had been removed (the Set still existed, empty), so throwError treated the error as handled: after unsubscribing from onError, play()/pause()/seek*() failures vanished silently. This is a regression from refactor: events logic #4798, which dropped the listener count that Handle multiples event listeners #4708 had added.
• wrapPromise re-threw from inside its own .catch when nobody listened to onError, so the outer promise never settled: await player.initialize() on a native rejection hung forever and logged an unhandled rejection. With a listener it rejected with undefined.
• release() called twice inside the 5 s grace window ran __destroy again: native release() is idempotent on both platforms, but the JS side cleared events again, called native release() again and restarted the grace timer that keeps the native object reachable.

Changes

• sourceFactory.ts: build the native config as a new object instead of mutating the input.
• VideoPlayerEventsBase.ts: report "nobody listening" when the listener set is empty.
• VideoPlayer.ts: one reportError path (parse, notify onError, return the parsed error) shared by the synchronous throwError and by wrapLoad, which runs the native load itself so that a synchronous throw (replaceSourceAsync with an invalid source, a released player) is reported like a native rejection; the promise always rejects with the parsed error. Loads carry a generation counter: a cancellation whose load was superseded by a newer load from JS only rejects, any other cancellation (the native player was released, e.g. by replaceSourceAsync(null)) is reported through onError like every other failure. __destroy is guarded by a released flag.
• VideoError.ts: player/cancelled and source/cancelled added to the code unions; both platforms already emit them.
• Unit tests: source normalization, event routing, VideoPlayer error propagation (including both cancellation cases) and release, useVideoPlayer; shared native mocks now record created players and keep emitter listeners.
• Docs and the agent skill (references/v7/events.md): the async methods reject as well as call onError; the synchronous ones keep the "callback instead of throw" contract; the rules are stated for iOS and Android, web has its own VideoPlayer and reports through onError with web/* codes.

Behavior changes

Ticked as a behavior change below. What apps see differently when something fails:

1. With an onError listener, initialize(), preload() and replaceSourceAsync() now reject with the error in addition to calling onError. Previously they rejected with undefined, so code that awaits them without a catch already saw an unhandled rejection; it now carries a VideoRuntimeError. Without a listener they used to hang; they now reject.
2. A load superseded by a newer initialize()/preload()/replaceSourceAsync() from JS no longer reaches onError as player/cancelled; it only rejects. A user switching sources mid-load is not a playback failure. A cancellation with no newer load, which both platforms produce once the native player has been released, still reaches onError as before.
3. Errors thrown after the last onError listener is removed are thrown again instead of dropped.
4. Two error codes are added to the exported unions: player/cancelled, source/cancelled.

Interplay with #5135 (async onError from native): no double delivery. On both platforms the load promises reject and never emit the native onError (HybridVideoPlayer.kt / HybridVideoPlayer.swift document this), so a rejected initialize() reaches onError once. The E2E error flows assert exactly one onError and are green on this branch.

Platforms affected

JS core of the native players. The web player (VideoPlayer.web.ts) has its own implementation and is not touched.

• 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: 251 tests pass (40 new library tests in this PR). bun typecheck and bun lint pass.
• Against the library source on master, 12 of the new tests fail: the empty-listener event trigger and the throw-again case, the three promise propagation cases, the two cancellation cases, the two replaceSourceAsync cases, the release case, the config mutation guard and the two useVideoPlayer recreate cases.
• The E2E gate (Android 0.77/0.82/0.87, iOS 0.87) is green on this branch. The flows only cover success paths and the asynchronous 404/broken-manifest errors; the promise and listener paths are covered by the unit tests, which is the right level for them.
• The player recreate path is inferred from useVideoPlayer/useManagedInstance and covered by the hook tests with mocked native modules; it was not reproduced in a rendered app.
• No new Maestro flow: the E2E test app sets initializeOnCreation explicitly and keeps its onError listener attached, so none of these paths are reachable from the current scenarios.

Merge order

#5098 no longer touches CONTRIBUTING.md, so the two PRs merge cleanly in either order.

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.