Flipkart: a daily snapshot from sparse changes

Constraints

1. 1quantity on a given day is the most recent change on or before that day — the last known value carried forward.
2. 2A SKU appears on a day only if it had a change at some point on or before it. SKU-C's first change is on 3 March, so it has no row for 2 March.
3. 3SKU-D has no change inside the window at all before 4 March, and must still be reported on 2 and 3 March at its February quantity.
4. 4Two changes on the same day are resolved by change_id: the higher one is the closing quantity for that day.
5. 5source is 'changed' when the day had its own change and 'carried' when the value came from an earlier day.
6. 6Order by sku, then report_day.

Worked example

SKU-B was set to 120 on 28 February, restated twice on 3 March — to 90, then 75 — and set to 210 on 5 March. The snapshot reads 120 carried on 2 March, 75 changed on 3 March, 75 carried on 4 March and 210 changed on 5 March. Join on changed_on = report_day and the carried days vanish: SKU-B reports only two of the four days, SKU-D disappears from the window entirely, and 3 March comes back twice — once at 90 and once at 75 — because the same-day restatement was never resolved.

What this tests

Building a dense snapshot from a sparse change log: a spine of days joined on a range rather than on equality, with a deterministic rule for several changes in one day.