feat(dashpay): authorize a token purchase from a DashConnect link - #1109

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `DashWallet/Sources/UI/DashConnect/ConnectionsViewModel.swift`:
- [BLOCKING] DashWallet/Sources/UI/DashConnect/ConnectionsViewModel.swift:177-185: An ambiguous post-submit failure can turn Retry into a second purchase
  Each call to `approveTokenPurchase` builds, signs, and submits a new direct purchase. The SDK can fail while awaiting confirmation after the transition has already reached Platform, but this catch path describes every error as an incomplete request and leaves the same sheet ready to approve again. If the first transition was accepted despite a finality timeout or similar DAPI failure, the retry can use the identity's next nonce and buy the tokens a second time. Distinguish deterministic pre-submit failures from ambiguous post-submit outcomes; for an ambiguous result, dismiss or disable retry and tell the user to verify the identity's tokens and credit balance before initiating another purchase.

In `DashWallet/Sources/Models/DashConnect/PlatformDashConnectDataSource.swift`:
- [SUGGESTION] DashWallet/Sources/Models/DashConnect/PlatformDashConnectDataSource.swift:635-658: Validate the displayed token ID against the purchase being rebuilt
  The approval request copies `tokenId` directly from the untrusted serialized transition, but approval rebuilds the operation solely from `dataContractId` and `tokenContractPosition`; the SDK derives the actual token ID and never receives `request.tokenId`. A crafted payload can therefore display the identifier of one token while purchasing another token selected by the contract and position. Validate that the parsed ID equals the token ID derived from those fields before presenting the sheet, or remove the Token ID row so the UI does not authenticate a value that execution ignores.
- [NITPICK] DashWallet/Sources/Models/DashConnect/PlatformDashConnectDataSource.swift:672-675: Describe expectedTotalCost as a maximum rather than an exact-price guarantee
  Platform rejects the purchase when the current required price exceeds `expectedTotalCost`, but a lower current price is accepted and the lower amount is charged. The comment therefore overstates the invariant by claiming that the charged amount cannot diverge from the displayed amount. The corresponding `DashConnectTokenPurchaseRequest.totalAgreedPriceCredits` comment should also describe this value as the maximum approved cost.

In `DashWalletTests/DashConnect/PlatformDashConnectDataSourceTests.swift`:
- [SUGGESTION] DashWalletTests/DashConnect/PlatformDashConnectDataSourceTests.swift:165-199: Add compile-ready coverage for token-purchase parsing and price conversion
  The existing parser test exercises only the renamed identity-update branch. The newly introduced token-purchase mapping, including owner ID, contract ID, token ID, position, count, and agreed price, has no regression coverage despite being directly testable through the parser's injected closure. Add a token-purchase branch test and boundary cases for converting Platform credits to DASH, including zero, a normal whole-duff value, and a value with sub-duff credit precision. These tests remain valuable as compile-ready coverage while the repository's unit-test runner is broken.

In `DashWallet/Sources/UI/DashConnect/ApproveTokenPurchaseSheet.swift`:
- [NITPICK] DashWallet/Sources/UI/DashConnect/ApproveTokenPurchaseSheet.swift:70-73: Render the full Platform-credit precision on the approval sheet
  Platform credits have 11 decimal places relative to DASH, but `formattedDashAmount` limits the displayed amount to 8 fractional digits. When `totalAgreedPriceCredits` is not divisible by 1,000, the sheet rounds away the sub-duff remainder while the exact credit amount is passed to `expectedTotalCost` and charged. The discrepancy is less than one duff, but this is a money-authorization surface and the displayed amount should preserve all 11 credit-backed decimal places.

In `DashWallet/Sources/Models/DashConnect/DashConnectModels.swift`:
- [NITPICK] DashWallet/Sources/Models/DashConnect/DashConnectModels.swift:63-70: Reuse the existing credits-per-DASH definition
  This introduces another literal definition of the Platform credits conversion even though `PlatformCreditsFormatter.creditsPerDash` is already internal and available to this module. The same divisor also has private copies in two payment views. Reusing the existing definition here prevents the money-display conversion from drifting independently.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `DashWallet/Sources/UI/DashConnect/ApproveTokenPurchaseSheet.swift`:
- [BLOCKING] DashWallet/Sources/UI/DashConnect/ApproveTokenPurchaseSheet.swift:149-151: Display token quantities in their declared denomination
  This formats the raw purchase amount as an integer under the label "Tokens". The parser copies tokenCount unchanged into the request, and approveTokenPurchase passes that same value to tokenPurchase(amount:); no contract denomination is resolved or applied anywhere along this path. For an eight-decimal token, 100,000,000 base units therefore appear as 100,000,000 tokens even though they represent one token. The flow neither restricts contracts to zero-decimal tokens nor identifies the displayed quantity as base units, so the approval can materially overstate what the user is buying. Preserve the raw amount for submission, but derive the displayed quantity from verified contract conventions in the service/model, or explicitly label it as base units when denomination metadata is unavailable.
- [NITPICK] DashWallet/Sources/UI/DashConnect/ApproveTokenPurchaseSheet.swift:70-73: Render the full Platform-credit precision on the approval sheet
  (existing thread: https://github.com/dashpay/dashwallet-ios/pull/1109#discussion_r3954766347)
  The eleven-digit formatter fixes small-price rounding, but totalPriceDashText delegates to PlatformCreditsFormatter.dashString, which converts UInt64 credits through Double before formatting. Executing the exact-head formatter with 10,000,000,000,000,001 credits produces "100000 DASH" instead of "100000.00000000001 DASH". The submitted ceiling remains the original integer, so the approval text still loses precision for large amounts. Preserve Decimal or integer arithmetic through final rendering and add totalPriceDashText assertions above Double's exact-integer range; the new conversion tests currently exercise only totalPriceDash.

In `DashWallet/Sources/UI/DashConnect/ConnectionsViewModel.swift`:
- [NITPICK] DashWallet/Sources/UI/DashConnect/ConnectionsViewModel.swift:116-120: Route second-request feedback to the active purchase sheet
  The expanded guard refuses a second request while either approval sheet is open, but always assigns approveError. ConnectionsScreen.tokenPurchaseSheet(for:) passes only purchaseApproveError to the purchase sheet, so a second request during token approval is silently refused from the user's perspective. Assign purchaseApproveError when pendingTokenPurchase is set and approveError otherwise, so the explanation appears on the sheet that owns the screen.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `DashWallet/Sources/Models/DashConnect/PlatformDashConnectDataSource.swift`:
- [BLOCKING] DashWallet/Sources/Models/DashConnect/PlatformDashConnectDataSource.swift:721-726: Recheck the active identity after authentication before submitting the purchase
  The ownership check is performed before `authorize()`, but `authorize()` awaits user interaction. If the active identity changes while the authentication prompt is open, the code proceeds with the previously captured `context` and constructs the signer for that stale identity. The purchase must re-resolve the active wallet/identity after authentication and reject if it no longer matches `request.ownerId`, immediately before creating the signer and submitting the purchase.
- [BLOCKING] DashWallet/Sources/Models/DashConnect/PlatformDashConnectDataSource.swift:666-710: Do not authorize token quantities from stale local decimals
  The quantity shown on the approval sheet is scaled using only the wallet's cached `PersistentToken.decimals` row. No current contract state is fetched or revalidated before approval, while token denomination metadata is mutable on Platform. If the contract changes its decimals after the wallet's last synchronization, the sheet can display a materially different quantity from the unchanged base-unit amount passed to `tokenPurchase`. Resolve the denomination from current verified contract state immediately before presenting or approving the request, or invalidate the approval when the current denomination differs from the displayed value; if it cannot be verified, show base units and do not imply a token-denominated quantity.

In `DashWallet/Sources/UI/DashConnect/ApproveTokenPurchaseSheet.swift`:
- [NITPICK] DashWallet/Sources/UI/DashConnect/ApproveTokenPurchaseSheet.swift:70-73: Render the full Platform-credit precision on the approval sheet
  (existing thread: https://github.com/dashpay/dashwallet-ios/pull/1109#discussion_r3954766347)
  `totalPriceDashText` now uses `PlatformCreditsFormatter.dashString`, but that formatter converts the `UInt64` credit amount through `Double` before formatting. `Double` cannot exactly represent every valid credit value above 2^53, so a large price can be displayed rounded even though the exact `UInt64` is still passed as `expectedTotalCost` and may be charged. Format the integer credits using integer/Decimal string arithmetic rather than `Double`, and add a regression test for a value above 2^53.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `DashWalletTests/DashConnect/PlatformDashConnectDataSourceTests.swift`:
- [SUGGESTION] DashWalletTests/DashConnect/PlatformDashConnectDataSourceTests.swift:291-293: Make token-formatting expectations match the locale-aware renderer
  The unknown-denomination branch renders through Decimal.string, which uses formatted(.number) and includes locale-dependent grouping. Executing the exact production model and this test body under en_US produces "100,000,000", so the assertion expecting "100000000" fails. The fractional test below also hardcodes a period although its NumberFormatter uses the current locale. Define the intended grouping and locale contract, then make the implementation and assertions agree; test the rendered output with deterministic locale-aware expectations.

In `DashWallet/Sources/Models/DashConnect/DashConnectModels.swift`:
- [NITPICK] DashWallet/Sources/Models/DashConnect/DashConnectModels.swift:87-88: Render the full Platform-credit precision on the approval sheet
  Using PlatformCreditsFormatter removes the former eight-fractional-digit limit, but that formatter first converts the UInt64 credits through Double. Executing the current implementation with 10_000_000_000_000_001 credits renders "100000 DASH" instead of "100000.00000000001 DASH", while tokenPurchase receives the exact integer as expectedTotalCost. The switch to an eleven-digit formatter therefore fixes ordinary sub-duff values but does not preserve full credit precision across the accepted range. Use decimal or integer arithmetic in the shared formatter and add boundary assertions against totalPriceDashText; the existing totalPriceDash assertions do not exercise the approval sheet's rendering path.