Vulnerability: Stargate `STG` rewards are accounted incorrectly by `StakedStargateAM.sol`
Severity: medium

Description:
Stargate LP_STAKING_TIME contract clears and sends rewards to the caller every time `deposit()` is called but StakedStargateAM does not take it into account.\\nWhen either mint() or increaseLiquidity() are called the `assetState[asset].lastRewardGlobal` variable is not reset to `0` even though the rewards have been transferred and accounted for on stargate side.\\nAfter a call to mint() or increaseLiquidity() any subsequent call to either mint(), increaseLiquidity(), burn(), decreaseLiquidity(), claimRewards() or rewardOf(), which all internally call _getRewardBalances(), will either revert for underflow or account for less rewards than it should because `assetState_.lastRewardGlobal` has not been correctly reset to `0` but `currentRewardGlobal` (which is fetched from stargate) has:\\n```\\nuint256 currentRewardGlobal = _getCurrentReward(positionState_.asset);\\nuint256 deltaReward = currentRewardGlobal - assetState_.lastRewardGlobal; ❌\\n```\\n\\n```\\nfunction _getCurrentReward(address asset) internal view override returns (uint256 currentReward) {\\n    currentReward = LP_STAKING_TIME.pendingEmissionToken(assetToPid[asset], address(this));\\n}\\n```\\n\\nPOC\\nTo copy-paste in USDbCPool.fork.t.sol:\\n```\\nfunction testFork_WrongRewards() public {\\n    uint256 initBalance = 1000 * 10 ** USDbC.decimals();\\n    // Given : A user deposits in the Stargate USDbC pool, in exchange of an LP token.\\n    vm.startPrank(users.accountOwner);\\n    deal(address(USDbC), users.accountOwner, initBalance);\\n\\n    USDbC.approve(address(router), initBalance);\\n    router.addLiquidity(poolId, initBalance, users.accountOwner);\\n    // assert(ERC20(address(pool)).balanceOf(users.accountOwner) > 0);\\n\\n    // And : The user stakes the LP token via the StargateAssetModule\\n    uint256 stakedAmount = ERC20(address(pool)).balanceOf(users.accountOwner);\\n    ERC20(address(pool)).approve(address(stakedStargateAM), stakedAmount);\\n    uint256 tokenId = stakedStargateAM.mint(address(pool), uint128(stakedAmount) / 4);\\n\\n    //We let 10 days pass to accumulate rewards.\\n    vm.warp(block.timestamp + 10 days);\\n\\n    // User increases liquidity of the position.\\n    uint256 initialRewards = stakedStargateAM.rewardOf(tokenId);\\n    stakedStargateAM.increaseLiquidity(tokenId, 1);\\n\\n    vm.expectRevert();\\n    stakedStargateAM.burn(tokenId); //❌ User can't call burn because of underflow\\n\\n    //We let 10 days pass, this accumulates enough rewards for the call to burn to succeed\\n    vm.warp(block.timestamp + 10 days);\\n    uint256 currentRewards = stakedStargateAM.rewardOf(tokenId);\\n    stakedStargateAM.burn(tokenId);\\n\\n    assert(currentRewards - initialRewards < 1e10); //❌ User gets less rewards than he should. The rewards of the 10 days the user couldn't withdraw his position are basically zeroed out.\\n    vm.stopPrank();\\n}\\n```\\n

Impact:
Users will not be able to take any action on their positions until `currentRewardGlobal` is greater or equal to `assetState_.lastRewardGlobal`. After that they will be able to perform actions but their position will account for less rewards than it should because a total amount of `assetState_.lastRewardGlobal` rewards is nullified.\\nThis will also DOS the whole lending/borrowing system if an Arcadia Stargate position is used as collateral because rewardOf(), which is called to estimate the collateral value, also reverts.

Recommended mitigation:
Adjust the `assetState[asset].lastRewardGlobal` correctly or since every action (mint(), `burn()`, `increaseLiquidity()`, `decreaseliquidity()`, claimReward()) will have the effect of withdrawing all the current rewards it's possible to change the function _getRewardBalances() to use the amount returned by _getCurrentReward() as the `deltaReward` directly:\\n```\\nuint256 deltaReward = _getCurrentReward(positionState_.asset);\\n```\\n