Promotion package omits LightningComponentBundle that was deleted and re-added within the same work item (NEW→DELETE→NEW netted as deleted)

## Bug

Promoting a single work item (integ → UAT) fails repeatedly:

```
Contract_Withdrawal_Screenflow: Get_URL_Context (Action) - We can't find the c:flowUrlContext action. (...)
```

The generated deploy package (verified via `DeployRequest` component details in the target org) contained 497 components including the Flow, but **zero `LightningComponentBundle`** and no destructive changes — `flowUrlContext` was silently omitted. The bundle exists on the work item branch and in the source stage branch.

## Root cause

`WorkItemComponent` rows for the bundle on this work item:

| ChangedOn | ChangeType |
|---|---|
| Jul 7 12:09 | NEW |
| Jul 7 12:35 | DELETE (bundle removed in a later commit) |
| Jul 8 08:40 | NEW (re-added in a later commit) |

The first two commits were also synced twice under different SHAs (branch was rewritten), giving `NEW, NEW, DELETE, DELETE, NEW`. Package aggregation netted the bundle as deleted despite the chronologically last change being NEW, so it was excluded from the package while the Flow referencing it was included → deployment can never succeed.

## Workaround

Deleted the two `DELETE` `WorkItemComponent` rows via API and re-ran the promotion.

## Expected

Netting must follow commit order (`ChangedOn`, latest wins): NEW → DELETE → NEW ⇒ bundle included in the package.

Start by tracing the package aggregation that processes WorkItemComponent rows and inspect how ChangedOn and ChangeType are netted. Reproduce the NEW → DELETE → NEW sequence, including duplicate synced rows, and verify that the latest chronological change includes the LightningComponentBundle without destructive changes.

Written by the indexing model from the issue text.