Merge customers and preserve history

##### Question Implement `mergeCustomers(String oldId, String newId)` for a payments/ledger platform. The call absorbs `oldId` into the survivor `newId` while preserving every account's balance and complete, immutable transaction history. Accounts are not coalesced — each account, with its history and balances, stays attached to its own account id. Design the full merge and explain your reasoning for each of the following: 1. **Identifier unification** — How do you unify the two identities so that, from the moment of merge commit, both `oldId` and `newId` resolve to a single canonical identity for all reads and future writes? 2. **Ownership remap** — How do you reassign ownership metadata across the entities that reference a customer (accounts, payment instruments, transfers, beneficiaries, etc.) without rewriting the ledger? 3. **Re-link historical and scheduled items** — How do you re-link historical payments/transfers and recurring/scheduled items so nothing is lost or double-executed? 4. **Pending / held items** — How do pending or held transactions, authorizations, and in-flight transfers continue to settle correctly after the merge? 5. **Conflict & duplicate resolution** — How do you handle `customerId` collisions and uniqueness conflicts (e.g. duplicate payment methods on the same token, identical scheduled items, beneficiary collisions, single-primary constraints, per-customer unique nicknames)? Give deterministic policies. 6. **Indexes & caches** — How do you update or invalidate indexes and caches, including the **top-N payers / top-N spenders** structure, so leaderboards stay correct immediately after the merge? 7. **Post-merge query correctness** — How do balances, transaction history, and top-N aggregates remain correct (no loss, no double-counting) for queries issued by either id? 8. **Atomicity & consistency** — What are your atomicity and system-wide consistency guarantees? How do you make the operation idempotent (repeating a merge is a no-op) and safe under concurrent merges (including chains A→B then B→C)? 9. **Complexity** — Analyze time and space complexity of the merge and of the post-merge read path.