fix(ios): serialize UInt64 transaction IDs as strings to prevent E_DEVELOPER_ERROR during finishTransaction

[Aflexon]

This pull request resolves a serialization issue affecting transaction identifiers (id and originalID) for iOS. We've observed transaction IDs—particularly from family-shared subscriptions—with UInt64 values exceeding JavaScript’s MAX_SAFE_INTEGER (2^53 - 1), such as 504319184420155588.

When these large integer IDs are transmitted from native Swift code to JavaScript via the React Native bridge, they lose numeric precision. This loss causes transaction IDs to become corrupted, resulting in errors like E_DEVELOPER_ERROR with the message Invalid transaction Id when calling finishTransaction with IDs obtained from the purchaseUpdatedListener. Consequently, transactions may fail to complete properly.

Proposed Changes

1. Serialize transaction identifiers (id, originalID) explicitly as strings to maintain numerical precision.
2. Retain numeric serialization for timestamp fields (millisecondsSince1970), as they currently do not risk exceeding JavaScript's precision limit.

[Copilot]

Pull Request Overview

This PR resolves an issue with large UInt64 transaction IDs being truncated on the React Native bridge by serializing them as strings.

• Changed the transaction identifier type in the TransactionSk2 interface from number to string.
• Updated the purchase mapping to use the new string-typed transaction identifier.

Files not reviewed (1)

• ios/IapSerializationUtils.swift: Language not supported

Comments suppressed due to low confidence (2)

src/types/appleSk2.ts:114

• Changing the 'id' type from number to string addresses the precision issue, but please verify that all consumers of this field are updated to expect a string.

id: string;

src/types/appleSk2.ts:192

• Removing the explicit conversion to string is logical since 'id' is now a string; please ensure that all related interfaces and usage correctly reflect this change.

transactionId: id,