Move sync change-tracking callback wiring to SDK SyncDomainTracker

[variablefate]

Context

SyncCoordinator currently hardcodes the mapping of "when this changes, mark that domain dirty":

settings.onProfileChanged = { store?.markDirty(.profile) }
driversRepo.onDriversChanged = { source in
    guard source == .local else { return }
    store?.markDirty(.followedDrivers)
}

This is protocol semantics — "profile name changes → Kind 0 sync needed" — that the SDK should own. The app shouldn't be thinking about which Nostr event kinds correspond to which domain changes.

What needs doing

1. Create SyncDomainTracker (or extend RoadflareSyncStateStore) in the SDK
2. Move change-tracking callback setup into SDK: tracker.wireCallbacks(settings:, drivers:, ...)
3. The SDK defines the mapping: settings changes → profile dirty, driver changes → followedDrivers dirty, etc.
4. Simplify app-layer SyncCoordinator to call tracker.wireCallbacks() during setup
5. Keep performStartupSync() and flushPendingSyncPublishes() in SyncCoordinator as-is (correct app-layer orchestration)

Why this matters

• The "which domain dirties when" mapping is protocol knowledge, not iOS knowledge
• If a new sync domain is added, the SDK should define its dirty-tracking, not require app changes
• Smallest of the three SDK boundary fixes — good cleanup after Migrate RideStatePersistence to SDK-based RideStatePersistenceRepository #27 and Extract LocationCoordinator key sync logic to SDK LocationSyncCoordinator #28

Pattern reference

SyncDomainResolver already owns the resolution logic in the SDK. SyncDomainTracker would own the detection side, completing the SDK's ownership of the sync lifecycle.

[variablefate]

Note from PR #34 review: RideCoordinator.backupRideHistory() publishes ride history independently of SyncCoordinator, with its own markPublished/markDirty bookkeeping. This creates a dual-path pattern where both the coordinator and SyncCoordinator can publish the same domain without coordination. When #29 consolidates sync wiring into the SDK, this should be unified — ride history backup publishing should route through a single path regardless of whether it's triggered by ride completion, manual deletion, or reconnect flush.