[kristofferkarlsson93]

Description

The iOS implementation caches the offset between wall time and systemUptime for converting Core Motion timestamps to Unix microseconds. Uptime excludes system sleep, so this offset can become stale while the process remains alive. Subsequent timestamps can fall behind wall time, including after cancelling and restarting a subscription.

This PR converts timestamps using the current clock pair at each native callback, preserving the measurement's age. The shared helper is used by motion sensors and the barometer before dispatch to the main queue. It also adds five deterministic Swift tests to the existing RunnerTests target and runs them in iOS CI. The Dart API is unchanged.

Validation

• Dart analysis and all 10 existing sensor-package/platform-interface unit tests passed.
• Five native tests passed on the iPhone 17 / iOS 27.0 simulator: conversion, simulated sleep, delayed delivery, sample spacing and clock adjustment. A cached-offset variant fails the sleep and clock-adjustment tests.
• iOS simulator/debug and unsigned device/release builds passed.
• Swift formatting and git diff --check passed.

Environment: Flutter 3.47.7, Dart 3.13.5, Xcode 27.1.

Verification limits

Physical iPhone sleep/wake behavior has not been verified for this patch; the unit tests simulate sleep. Device verification should compare fresh samples before and after locking/resuming the same process, checking that currentUptime - sensorTimestamp remains a plausible sample age. This change does not reconstruct historical samples' original wall time across sleep.

Related Issues

No existing issue linked.

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I titled the PR using Conventional Commits.
• I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
• All existing and new tests are passing.
• The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
• No, this is not a breaking change.