v4.0.5 — Fix notification dedup regression

Fix: Notification Dedup Regression

Severity: High — impacts API response correctness for transaction queries

What was broken

A regression in v4.0.4 caused notification traces (e.g., eosio.token::transfer notifications to sender/receiver) to be stored as separate documents instead of being merged into a single action with multiple receipts. This caused get_transaction to return duplicate transfer actions, leading exchange integrations to triple-count deposits.

What this fixes

Indexer — Changed the dedup grouping key to use creator_action_ordinal, which correctly distinguishes notifications (merge with parent) from genuinely distinct duplicate actions (keep separate, per #148).

API (no re-index required) — Both v1 and v2 get_transaction handlers now re-group fragmented notification documents on read. This means:

• ✅ Data already indexed with v4.0.4 produces correct responses immediately after upgrading
• ✅ Newly indexed data is stored efficiently (merged at index time)
• ✅ v2 response now includes a notified field (comma-separated list of notified accounts)

What you need to do

1. Pull and rebuild from v4.0.5
2. Restart the API process
3. (Optional) Re-index from blocks to reclaim ~3x storage overhead from fragmented documents

Changed files

• src/indexer/helpers/action-dedup.ts — fixed grouping key
• src/api/helpers/regroup-actions.ts — new shared re-grouping helper
• src/api/routes/v2-history/get_transaction/get_transaction.ts — re-group on read + notified field
• src/api/routes/v1-history/get_transaction/get_transaction.ts — re-group on read
• tests/unit/action-dedup.test.ts — realistic Antelope ordinals
• tests/unit/regroup-actions.test.ts — new API re-grouping tests