BD-5772: Fix CDI UPDATED_AT recurring sync example

[atom-evens]

Summary

A customer reported a contradiction in the Cloud Data Ingestion Best Practices page. The doc states that Braze syncs rows where UPDATED_AT is "equal to or later than" the stored timestamp (inclusive boundary), and a separate section on the same page explicitly warns about duplicate data resulting from this inclusive behavior. However, the recurring sync example contradicted both of these by:

• Second run: Claiming "none of these rows will be synced," even though customer_5678 has an UPDATED_AT equal to the stored timestamp and should be re-synced per the inclusive boundary rule.
• Third run: Claiming "only one row will sync," when two rows should sync (the new row plus the row with UPDATED_AT equal to the stored timestamp).

Changes

• Second run explanation: Now correctly states that the new customer_9012 row won't sync (its timestamp is earlier), but the existing customer_5678 row is re-synced because its UPDATED_AT equals the stored timestamp. Adds a cross-reference to the "Make sure the UPDATED_AT time isn't the same time as your sync" section.
• Third run explanation: Now correctly states that two rows sync: the new customer_1234 row (later than stored) and the existing customer_5678 row (equal to stored).

Test plan

• Verify the second run and third run explanations are consistent with the "equal to or later than" rule stated earlier on the page.
• Verify the cross-reference link to "Make sure the UPDATED_AT time isn't the same time as your sync" resolves correctly.

Made with Cursor

[Copilot]

Pull request overview

Fixes a contradiction in the Cloud Data Ingestion best practices doc by updating the recurring sync example to match the stated inclusive UPDATED_AT boundary behavior.

Changes:

• Corrects the “second run” narrative to reflect that rows with UPDATED_AT equal to the stored timestamp are re-synced.
• Corrects the “third run” narrative to reflect that two rows sync (newer + equal-to-stored).
• Adds an in-page cross-reference to the section explaining duplicate sync behavior caused by inclusive boundaries.