governance-rewards: add executeImpl unique-beneficiary guard (next version bump)

[gyorgybalazsi]

Context

From the independent review of #255 (finding #1). SetupCouponReassignmentDelegation.executeImpl re-validates the split at execute time (non-empty, ≤20, each percentage in (0,1], sum == 1.0) as defense-in-depth for a direct ledger submit that bypasses DecMan's HTTP API. It is missing the uniqueness check that the other guards mirror and that the on-ledger RewardCoupon_AssignBeneficiaries enforces (require "Beneficaries are unique", splice-amulet Amulet.daml).

The Rust-side guard was added in #255 (validate_reward_beneficiaries now rejects duplicates at propose time), so the realistic path is covered. This issue tracks completing the DAML executeImpl mirror.

Why it was deferred (not done in #255)

Adding the assert changes the compiled governance-rewards-v1 DAR. The current 0.1.3 (package-id 1ff1b18c89d71a4176c9cf4d5eff215127b2a3297136a0e17be5125f27611a4f) is already vetted on devnet (confirmed via __packages) and is the committed releases/v1/governance-rewards-v1-0.1.3.dar the localnet IT distributes. Re-hashing 0.1.3 in place would collide with the vetted package (same name+version, different hash). The clean path is a version bump, not an in-place regen.

What to do

1. Bump governance-rewards 0.1.3 → 0.1.4 (daml/governance-rewards/daml.yaml).
2. Add to SetupCouponReassignmentDelegation.executeImpl (after the percentage check):

   assertMsg "beneficiaries must be unique" (unique (map (.beneficiary) beneficiaries))
   

   (add import DA.List (unique)).
3. Repoint all governance-rewards-v1-0.1.3.dar pins → 0.1.4: the data-dependencies in the sibling daml.yaml files, crates/decman/tests/common/phases/distribute_dars.rs (DAR_FILES), and add releases/v1/governance-rewards-v1-0.1.4.dar. (#governance-rewards-v1 alias resolves by name, so default_package_config is unaffected.)
4. Re-add the DAML regression test (was staged in CIP-104 Mode A coupon-reassignment automation #255, removed with the assert):
   test_setup_duplicate_beneficiary_rejected — setupExecuteMustFail f [m1] [rb m2 0.5, rb m2 0.5].
5. dpm build --all; dpm test in governance-rewards-assign-test; deploy + vet 0.1.4 on devnet (additive alongside 0.1.3 — no un-vetting needed).

Priority

Low. Defense-in-depth only: the Rust guard (propose time) and the runtime require "unique" (assign time) already bracket this — the worst case without it is a bricked-but-harmless delegation created via a deliberate API bypass, never a misassignment. Bundle with the next governance-rewards version bump so the DAR churn/re-vet cost is shared.