* fix(lunchflow): refresh stored transaction on pending to posted
LunchflowItem::Importer keyed stored raw transactions but treated them
as immutable snapshots. When Lunchflow flipped a transaction from
pending to posted under a stable ID, fetch_and_store_transactions
skipped it as a duplicate and kept the stale pending snapshot. The
processor then re-imported it with isPending:true, so
ProviderImportAdapter#import_transaction never reached its
pending-clearing branch and the entry stayed stuck with a "Pending"
badge.
Index stored transactions by key (the Lunchflow ID, or a content hash
for the blank IDs Lunchflow returns for some pendings) and refresh the
stored snapshot in place when the upstream payload actually changed,
while still deduplicating by key to prevent unbounded growth.
Fixes#2735
* fix(lunchflow): preserve identical same-response blank-ID transactions
The stored snapshot was keyed with a Hash of key -> transaction, so two rows in one
sync response that share a content hash (Lunchflow returns blank IDs for some pending
transactions, and two genuinely distinct identical purchases hash the same) collapsed
into a single entry. The second row hit the existing-key branch as though it were a
duplicate, dropping a real transaction before LunchflowEntry::Processor could apply its
collision suffix.
Pool the existing snapshot into one bucket per key and match incoming rows one-for-one
(shift), so same-response collisions each claim their own slot or count as new. This
preserves every real transaction while still deduplicating across syncs (re-syncing the
same pair stays at two, not four) and refreshing pending -> posted transitions.
Adds a regression test for two identical blank-ID rows in the same response.
---------
Co-authored-by: agentloop <agentloop@localhost>
Co-authored-by: pro3958 <pro3958@users.noreply.github.com>
