feat(sync): execute provider update commands with safe replay

[tyler-dane]

What

The provider-update half of S28: routes an update of a single, provider-linked event to the owning provider (Google) when provider work is active, with replay-safe conflict handling — the "one safe replay" the ledger calls for. Cloud updates (S28.1), and series/move/delete, are unchanged/deferred.

The replay-safety problem

Unlike provider create (idempotent for free via a deterministic id + Google's 409 read-back), a successful patchEvent changes the version. So a crash-before-confirm retry would re-send the now-stale expected version → Google returns 412 → a naive executor reports versionConflict for an edit that actually landed. That's a false failure on a successful write.

The design: fetch-first

executeProviderUpdate:

1. Resolve the access token (transient refresh → pending; revoked/missing → failed, no provider call).
2. fetchEvent the provider's current state.
   • Gone / cancelled → failed{permanentProviderError} (nothing to update).
   • Already carries this command's intended content → the edit landed on a prior attempt → confirm at the current version, no second write (the safe replay).
3. Otherwise patchEvent conditionally (If-Match = the command's expected version). A genuine concurrent external edit → 412 → failed{versionConflict}; transient → pending.
4. Commit the new content + version to the canonical record via owner-scoped, non-upsert replaceExisting (no resurrection of a concurrently-deleted event), then confirm.

The content comparison only gates the replay shortcut, so a false miss fails safe: it falls through to the conditional patch, whose If-Match yields a spurious conflict at worst — never a silently-lost external edit.

Invitation

Per the decision, the update command carries the client-driven invitation (default none), passed straight to patchEvent.

Tests

• Executor (6, fake writer): patch-and-commit happy path (asserts If-Match + invitation pass-through), replay (fetched content matches intent → confirm, zero patch calls), genuine conflict → failed{versionConflict}, provider-event-gone → failed{permanentProviderError}, transient patch → pending, revoked credential → failed with no provider call.
• Dispatch (1): a provider-linked update under active mode routes to the executor and patches.
• Core: update defaults invitation to none; accepts an explicit one.

All core (490) + sync (364) suites green.

🤖 Generated with Claude Code