The mismatch between the lengths of the rewardTokens array and the items array in the _userRewardLock struct can lead to  potential vulnerabilities.
Audit: 2024-03-abracadabra-money-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-03-abracadabra-money/blob/1f4693fdbf33e9ad28132643e2d6f7635834c6c6/src/staking/LockingMultiRewards.sol#L614-L656


# Vulnerability details

## Impact
This will lead to incorrect reward distribution or potentially allow users to claim rewards for tokens that they should not be entitled to.
For example, if a reward token is removed from the `rewardTokens` array, the corresponding `RewardLockItem` in the items array would still exist, but the code would skip over it, potentially allowing users to claim those rewards even after the token has been removed.

The impact of this issue is high because it can lead to incorrect reward distribution, potentially allowing users to claim rewards they should not be entitled to or preventing them from claiming rewards they are entitled to. This can result in financial losses or unfair advantages for certain users, compromising the integrity and fairness of the reward system

## Proof of Concept
Here's how the issue arises:
1. Initially, when a user creates a reward lock, the items array in their `_userRewardLock` struct is initialized with the same number of elements as the `rewardTokens` array.
2. If the owner adds a new reward token using the `addReward` function, the `rewardTokens` array length increases by one.
3. When the user tries to claim their rewards or create a new reward lock, the code in the `_getRewards` function iterates over the `rewardTokens` array.
4. If the index i is greater than or equal to the length of the items array, a new lock item is created and added to the items array.
This logic works fine as long as the `rewardTokens` array is only appended with new tokens. However, if the owner removes or reorders the tokens in the `rewardTokens` array, the existing lock items in the items array may no longer align with the correct reward tokens.
For example, let's say the initial `rewardTokens` array is [tokenA, tokenB], and a user has a reward lock with two items: [itemA, itemB]. If the owner removes tokenA from the `rewardTokens` array, the items array will still have itemA, but it will now correspond to tokenB in the `rewardTokens` array. This mismatch can lead to rewards being incorrectly credited or claimed.

 Here's a hypothetical scenario demonstrating the vulnerability:
1. The `rewardTokens` array initially contains [tokenA, tokenB, tokenC].
2. A user creates a reward lock, and their items array contains [itemA, itemB, itemC].
3. The owner removes tokenB from the `rewardTokens` array, making it [tokenA, tokenC].
4. When the user tries to claim their rewards, the code will incorrectly associate itemB with tokenC, potentially leading to the user receiving the wrong rewards or losing their locked rewards for tokenB.

The potential issue lies in the _getRewards function, specifically in the following code snippet:

       for (uint256 i; i < rewardTokens.length; ) {
           address rewardToken = rewardTokens[i];
           uint256 rewardAm