SqlServerCT: surface stale sync anchors and make change retention con…

[adospace]

…figurable

Clients whose anchor fell out of the change tracking retention window stopped uploading updates without reporting an error. Update/Delete statements pass the target anchor into CHANGETABLE(CHANGES

, @last_sync_version); nothing guarded that on the upload path and the resulting error was swallowed by T-SQL, so the batch reported zero affected rows and the item was misread as a write conflict and dropped.

• Add SyncAnchorTooOldException (TableName, RequestedVersion, MinValidVersion) so callers can tell "reinitialize this client" from "transient, retry". It derives from InvalidOperationException, which keeps GetChangesAsync's existing contract while giving that path the same typed signal. It propagates unwrapped through SyncErrorException and SyncAgent.
• Guard ApplyChangesAsync against an anchor below CHANGE_TRACKING_MIN_VALID_VERSION, only for tables carrying Update/Delete items so first-time inserts still work, and also at the point an insert is converted into an update.
• Return SyncAnchor.Null rather than version 0 for a missing remote anchor row. Zero is not a sentinel: it is a real-looking version permanently below the retention floor. Applied to SqlServerCT and, for consistency with the other providers, to SqlServer (where 0 and -1 are equivalent since __CORE_SYNC_CT.ID is IDENTITY(1,1), so this is a naming fix rather than a behaviour change).
• Drop the BEGIN TRY/CATCH PRINT ERROR_MESSAGE() wrappers so a zero rowcount means only a genuine conflict. Those swallowed errors were load-bearing, so the two cases that relied on them are now handled explicitly: a duplicate key routes into the existing exists-check and retries as an update, and a constraint violation (547) defers the item to the next pass, preserving the out-of-order insert retry. When the retry loop stops making progress with a real error in hand it now throws instead of dropping the items with a warning.
• Log the exception and the accumulated messages on failure, and clear the message log per item so a failure no longer replays every message since the call began.
• Reconcile CHANGE_RETENTION on provisioning instead of only setting it when change tracking is first enabled, which is why .ChangeRetention(n) was silently ignored on every database that already had it on. Adds a ChangeRetentionUnit overload, validates the value, reports ALTER DATABASE permission failures clearly, and warns when the window is shorter than seven days. A database that already has change tracking on is only touched when the retention was configured explicitly.
• Switch the per-item ExecuteNonQuery to ExecuteNonQueryAsync, replace the UPDATE-then-INSERT anchor writes with MERGE to close the concurrent-sync race, and pass the anchor ID as SqlDbType.UniqueIdentifier throughout.
• Cover all of the above in SqlServerCTResilienceTests, and correct the README's change tracking example, which referenced builder methods that do not exist.