[P2-E2.5] Merge automation: operator-aware grouping

The settled shape dissolved most of this issue: purchases land on `MemberTraffic`, and the existing on-ledger merge choice now asserts operator consistency and preserves the operator through compaction (canton-network/splice-multi-sync#2), so no twin choice/trigger/threshold is needed and record growth is handled by the existing machinery.

Residual Scala work: the trigger selects merge candidates per `(member, syncId, migrationId)`, but the choice now refuses mixed-operator sets — after an operator rotation (re-registration of a sync id with a new operator), a candidate group holding both old- and new-operator records would fail to merge indefinitely. Group by operator as well (or exclude cross-operator sets), and scope the trigger's work per sync id (Itai's note in the design doc).

**Key files:** `apps/sv/.../automation/delegatebased/MergeMemberTrafficContractsTrigger.scala`

**Acceptance criteria:**
- [ ] Trigger groups by `(member, syncId, migrationId, operator)`; mixed-operator sets are never submitted
- [ ] Multiple purchases collapse to one record without changing totals; operator preserved (on-ledger assertion already covered by fork PR #2 tests)

**Depends on:** E1-3

**Epic:** ChainSafe/canton-extending-mainnet#65

_Source: `docs/planning/extending-mainnet-work-plan.md`; reworked 2026-07-27 after the buy-rung shape decision._

Start with apps/sv/.../automation/delegatebased/MergeMemberTrafficContractsTrigger.scala and the relevant section of docs/planning/extending-mainnet-work-plan.md. Trace how candidates are selected per sync id, then verify the acceptance criteria: grouping includes operator, mixed-operator sets are not submitted, and multiple purchases collapse without changing totals or the operator. Review the existing on-ledger assertion and fork PR #2 tests for expected operator-preservation behavior.

Written by the indexing model from the issue text.