Vulnerability: All operators can have ETH deposits regardless of the cap setted for them leading to miscalculated TVL
Severity: medium

Description:
Some operators might not be eligible for using some strategies in the LRT's underlying tokens. However, in default every operator can have ETH deposits which would impact the TVL/Exchange rate of the LRT regardless of they have a cap or not.\\nFirst, let's examine how an operator can have ETH deposit\\nAn operator can have ETH deposits by simply staking in beacon chain, to do so they are not mandatory to call EigenPods "stake" function. They can do it separately without calling the EigenPods stake function.\\nAlso, every operator delegator contract can call `verifyWithdrawalCredentials` to increase EigenPod shares and decrease the queued ETH regardless of they are active operator or they have a cap determined for BEACON_CHAIN_STRATEGY.\\nNow, let's look at how the TVL of ETH (BEACON_CHAIN_STRATEGY) is calculated in the AssetRegistry:\\n```\\nfunction getTVLForAsset(address asset) public view returns (uint256) {\\n        uint256 balance = getTotalBalanceForAsset(asset);\\n        if (asset == ETH_ADDRESS) {\\n            return balance;\\n        }\\n        return convertToUnitOfAccountFromAsset(asset, balance);\\n    }\\n\\n    function getTotalBalanceForAsset(address asset) public view returns (uint256) {\\n        if (!isSupportedAsset(asset)) revert ASSET_NOT_SUPPORTED(asset);\\n\\n        address depositPool_ = address(depositPool());\\n        if (asset == ETH_ADDRESS) {\\n            return depositPool_.balance + getETHBalanceInEigenLayer();\\n        }\\n\\n        uint256 sharesHeld = getAssetSharesHeld(asset);\\n        uint256 tokensInRio = IERC20(asset).balanceOf(depositPool_);\\n        uint256 tokensInEigenLayer = convertFromSharesToAsset(getAssetStrategy(asset), sharesHeld);\\n\\n        return tokensInRio + tokensInEigenLayer;\\n    }\\n\\n    function getETHBalanceInEigenLayer() public view returns (uint256 balance) {\\n        balance = ethBalanceInUnverifiedValidators;\\n\\n        IRioLRTOperatorRegistry operatorRegistry_ = operatorRegistry();\\n        -> uint8 endAtID = operatorRegistry_.operatorCount() + 1; // Operator IDs start at 1.\\n        -> for (uint8 id = 1; id < endAtID; ++id) {\\n            -> balance += operatorDelegator(operatorRegistry_, id).getETHUnderManagement();\\n        }\\n    }\\n```\\n\\nAs we can see above, regardless of the operators cap the entire active validator counts are looped.\\n```\\nfunction getEigenPodShares() public view returns (int256) {\\n        return eigenPodManager.podOwnerShares(address(this));\\n    }\\n\\n    function getETHQueuedForWithdrawal() public view returns (uint256) {\\n        uint256 ethQueuedSlotData;\\n        assembly {\\n            ethQueuedSlotData := sload(ethQueuedForUserSettlementGwei.slot)\\n        }\\n\\n        uint64 userSettlementGwei = uint64(ethQueuedSlotData);\\n        uint64 operatorExitAndScrapeGwei = uint64(ethQueuedSlotData  64);\\n\\n        return (userSettlementGwei + operatorExitAndScrapeGwei).toWei();\\n    }\\n\\n    function getETHUnderManagement() external view returns (uint256) {\\n        int256 aum = getEigenPodShares() + int256(getETHQueuedForWithdrawal());\\n        if (aum < 0) return 0;\\n\\n        return uint256(aum);\\n    }\\n```\\n\\nSince the operator has eigen pod shares, the TVL will account it aswell. However, since the operator is not actively participating on ether deposits (not in the heap order) the withdrawals or deposits to this specific operator is impossible. Hence, the TVL is accounting an operators eigen pod share which the contract assumes that it is not in the heap.\\nTextual PoC: Assume there are 5 operators whereas only 4 of these operators are actively participating in BEACON_CHAIN_STRATEGY which means that 1 operator has no validator caps set hence, it is not in the heap order. However, this operator can still have ether deposits and can verify them. Since the TVL accounting loops over all the operators but not the operators that are actively participating in beacon chain strategy, the TVL calculated will be wrong.

Impact:
Miscalculation of total ether holdings of an LRT. Withdrawals can fail because the calculated ether is not existed in the heap but the TVL says there are ether to withdraw from the LRT.

Recommended mitigation:
put a check on `verifyWithdrawalCredentials` that is not possible to call the function if the operator is not actively participating in the BEACON_CHAIN_STRATEGY.