fix(bindings): forwardMessage's priority crosses the iOS bridge as a required int

[bahdotsh]

Closes #417.

The problem

React Native forces every NSNumber argument to non-null, because numbers are not nullable on Android, and refuses a null one before the Swift method is entered. Neither the resolver nor the rejecter runs, so the promise never settles and await forwardMessage(...) hangs forever behind a redbox.

The TypeScript passed null whenever a caller omitted the priority, which made forwardMessage the one method in this bridge relying on a nullable number. As #417 documents, no spelling of the declaration fixes it: nullable is rejected at module load, unspecified and nonnull are both forced non-null, and a plain NSInteger did not match the Swift NSNumber?.

The fix

The nullability is removed rather than respelled, because the null carried no information in the first place:

• the core already does priority.unwrap_or(MessagePriority::Medium) (crates/offline-protocol/src/protocol/send.rs:259),
• ForwardMessageParams.priority already documented "defaults to Medium", and
• sendMessage already had the identical API and already resolves the default in TypeScript, crossing as a required int.

forwardMessage now matches its sibling exactly: TypeScript sends params.priority ?? MessagePriority.Medium, the shim takes NSInteger, Swift and Kotlin take Int, and each maps an unrecognised value back to Medium.

This is the RN bridge, not UniFFI output, so the UDL is untouched and no bindings were regenerated.

Impact

No caller sees a behaviour change on either platform: an omitted priority meant Medium before and means Medium now. The check that refused the null is inside #if RCT_DEBUG, so only development was affected. The public ForwardMessageParams type is unchanged.

Why a guard cannot hold this

react_native_ios_objc_shim_and_swift_agree_on_every_selector compares ABI classes, and a nullable number and a nullable object share one. Both halves agreed while React Native rejected the call anyway. So the rule is written down instead: both BRIDGE_MAINTENANCE.md and docs/bridges/swift.md lose the paragraph describing the breakage and gain the rule that a nullable number never crosses this bridge.

The TypeScript half is pinned by a new harness file, js-ci-harness/forward-priority.test.js, wired into npm run test:js. It covers the argument always being a number and the MessagePriority.Low-is-0 trap, where resolving the default with || instead of ?? would silently upgrade every Low forward to Medium.

Verification

Check	Result
cargo test --workspace --lib	pass
cargo clippy --workspace -- -D warnings	pass
iOS ABI/selector guards (5 tests)	pass
swiftc -typecheck, full hand-written iOS source set	pass, negative control confirmed at the changed method
Android :offlineprotocol:testDebugUnitTest (clean-dir copy)	BUILD SUCCESSFUL
npm run test:js (all 6 harness files)	pass
New harness cases mutation-tested	?? null and || each fail the case that covers them