Fix redundant device PATCH, preference/server divergence, and non-UTC scheduled workflows

[mohn93]

Fixes three bugs found while porting this SDK to Swift. Each is a separate commit with a regression test.

Fixes #5, fixes #6, fixes #7.

1. registerDevice PATCHed on every launch (#5)

registerDevice() persisted the raw OS permission but compared it against the effective value (osPermission && (savedPreference ?? true)). Any device whose developer had called setNotificationEnabled(false) while the OS permission was granted saw those two values differ permanently, so it sent a redundant PATCH update-device on every cold start, with a misleading Device permission status changed log line each time.

Now compares raw against raw. The developer preference already has its own write path through setNotificationEnabled, so it does not need to drive this check.

The resume-sync behaviour from [0.3.1] (commit c1369b9) is load-bearing here, so its tests in device_service_permission_resume_scenarios_test.dart and device_service_resume_permission_repro_test.dart were left untouched and all still pass.

2. Notification preference could diverge from the server (#6)

setNotificationEnabled() wrote the preference to SharedPreferences before the PATCH. When the PATCH failed the call threw, but local state had already changed — and because the method short-circuits when the local preference already matches, a retry returned success without ever contacting the server. The divergence was sticky: the device kept receiving notifications the user asked to stop, and recovery required toggling to the opposite value and back.

Now persists only after the server confirms.

This required amending one existing test. saves preference locally even if server call fails asserted exactly the behaviour being fixed — it was pinning the bug — so its assertion is inverted rather than a contradictory test being added alongside it. It is now does not save preference locally when the server call fails (regression for #6).

3. Scheduled workflows fired at the wrong time outside UTC (#7)

WorkflowExecutionRequest.toJson() used toIso8601String() on scheduledFor. Dart appends Z only when isUtc is true, so a local DateTime — what DateTime.now(), DateTime(...) and every date picker produce — serialised with no timezone designator, which the backend reads as UTC. A user at UTC+2 scheduling for 12:00 local had the workflow fire at 14:00 local; west of UTC it fired early. The error scaled with the offset and was silent.

Now normalises with toUtc(), which is a no-op on an already-UTC value so both inputs are correct. createScheduledWorkflowForSubscribers and createScheduledWorkflowForSegments gained a line noting that scheduledFor is an absolute instant and a local DateTime is converted.

Note this changes the value sent on the wire for callers passing local times. That value was wrong, so it is the fix rather than a behaviour change anyone could have been relying on deliberately — but it is the one change here with an externally visible effect, so worth a deliberate look.

The new test asserts the string ends with Z, which fails on the old implementation at any offset including UTC+0, so it is not silently passing on a UTC machine.

Verification

flutter test — 391 passing, same count before and after. dart analyze — 87 pre-existing info-level lints, zero new, none in the four files touched.

Not included

No version bump and no CHANGELOG entry — the release is yours to cut.

[mohn93]

Two formatting commits were added after the initial push, because CI's dart format --set-exit-if-changed gates the merge:

• 87e6663 formats the new test file added by this PR.
• b0d5d86 formats test/services/device_service_permission_resume_scenarios_test.dart, which is pre-existing drift on main and unrelated to these fixes. I verified it fails the format check on main too. It is included as its own commit so it can be dropped or split out if you would rather land it separately.

CI is green on b0d5d86. 391 tests passing.