refactor: share one UIHingeInteraction factory across the iOS module and view

[janicduplessis]

Description

The iOS TurboModule and the Fabric observer view each built their own UIHingeInteraction. Both carried the same __IPHONE_27_1 compile guard, the same @available(iOS 27.1, *) check, and the same UIHinge.status to string mapping, so any change to the hinge mapping had to be made twice and kept in sync by hand. Android already routes both of its consumers through a single HingeSource.

Solution

ios/HingeInteraction.mm now owns the SDK guard, the availability check, the interaction construction and the status/angle mapping, and hands the caller a plain payload array. Call sites just supply a handler. HingesMakeInteraction returns nil when the feature is unavailable, from an old SDK or a pre-27.1 runtime; both call sites then attach nothing and keep an empty snapshot, exactly as the module already behaved when it had no root view.

No behavior change.

Not covered: the only iOS reading available here is closed at 0 degrees, so the rest of the status mapping stays exercised only by the Android end to end check. No real foldable device, and no changing angle.

Test plan

iPhone Duo simulator on the iOS 27.1 runtime, built with Xcode 27.1 beta, Sensor lab:

• the NATIVE HINGE pill and NATIVE ANGLE 0.0° / closed come from the Fabric view path
• React hook: 0.000 rad · Observer: 0.000 rad comes from the TurboModule path, covering both the useHinges hook and a standalone createHingeObserver

Compile guard: built the Hinges pod target against the iOS 27.0 SDK with the default Xcode for generic/platform=iOS Simulator. It compiles clean, and nm -u on HingeInteraction.o lists only _objc_storeStrong, so nothing links against UIHingeInteraction when the SDK lacks it.

[janicduplessis]

Returning id<UIInteraction> rather than UIHingeInteraction * keeps this header buildable on SDKs that have no UIHingeInteraction declaration, so the guard stays confined to the .mm.