feat: add set redemption script fnc for ENA S2

[jparklev]

for the alpha (v.0.1.0) deployment

We got 1324... ENA for our cliff vest, and were told we'd have the same amount vested over time (if the ENA threshold balance is maintained). Because we didn't halve the Ethena sats pTokens for the alpha like we do for season 3 in the public release, future vesting rewards are not guaranteed. We will use redemption rights, and, if future rewards are lost, will scale the redemption rights down proportionally such that there will be excess pTokens at the end that will never be redeemable.

reward per p token calc:
Total kpSATs-2 (both claimed and unclaimed): 4178883670999999914762240
50% ENA vest: 132431200000000000000000
Rewards per p token (rounded down): 63381137368827226

In addition, we'll only be going with holders at the original snapshot, and won't update the redemption rights recipients if users sell or transfer their pTokens, as specified in the docs

This script:

1. Fetches pToken balances at the current block
2. Calculates redemption rights for each user based on their balance
3. Merges given distribution with calculated redemption rights
4. Saves pToken balance snapshot for future reference
5. Saves merged distribution with updated root

.env we'll use for the alpha kpSATS run:

...
PTOKEN_ADDRESSES=0xdFa21ceC8A46386F5d36F4b07E18BcCcA59f425B
POINTS_IDS=0x1852756d70656c206b506f696e743a20457468656e61205332066b7053415453
REWARDS_PER_P_TOKEN=63381137368827226
POINT_TOKEN_VAULT_ADDRESS=0x1EeEBa76f211C4Dce994b9c5A74BDF25DB649Fa1
VEST_SIZE=.50

For future runs, we'll have the script add to the existing redemption rights for each successive vest and we'll use the stored snapshot rather than creating a new one.

[stevenvaleri]

To be conservative, we could add a fork test that runs script in the setup, has this test redemption, and also test redemptions that are invalid and fail

[jparklev]

yes! like add this to the test suite ? Had a similar thought, and probably not a bad move

[stevenvaleri]

yes - like the test file would call setRedemptionENA30Oct24 from the script in the setup function and then you can run some tests to make sure users can claim as expected in diff scenarios - user with rr can claim, user with out can't, double check the conversion rate is expected, etc.

[stevenvaleri]

A few comments - most impt is the question on unclaimed pTokens.

[jparklev]

ty for the review @stevenvaleri

[stevenvaleri]

looks good!

[jparklev]

Pushed the unclaimed pToken fix @stevenvaleri!