Ensembles 3.1.0

• cancelSync() stops a sync in progress. Ensembles 2's cancelMergeWithCompletion: was never ported, so an app had no way to back a Cancel Sync button; suspendSync() only pauses. CoreDataEnsemble, SwiftDataEnsemble and both containers now have cancelSync(). The sync in progress stops at its next internal checkpoint: sync(options:) throws EnsembleError.cancelled (101), and the containers' sync() returns false and passes that error to didEncounterError. As in Ensembles 2, syncs already requested and still waiting their turn are cancelled too, including a container's automatic syncs, so a queued sync cannot undo the cancel; a sync requested after the call runs as normal. Work is kept in whole units (files downloaded, batches uploaded, phases completed), so the next sync carries on from there; a merge interrupted part way is discarded and redone. The ensemble stays attached. A sync paused with suspendSync() is cancelled at once without a resume; the suspension stays in place. With nothing running or requested the call has no effect. Asked for by a customer porting a Cancel Sync button from Ensembles 2.
• Documentation: detach and re-attach does not preserve edits made while detached. The Manual's troubleshooting chapter and the Sync Lifecycle article said local data was "preserved and re-imported". The re-import is a junior baseline, so where the cloud also holds a value for an attribute the cloud's value wins: edits made while detached are overwritten and objects deleted elsewhere come back, while new objects survive. The text now says so, the Detaching chapter says to stay attached and stop calling sync() to turn syncing off, and the Ensembles 2 migration pages no longer claim that unsynced E2 edits survive the upgrade.