Vulnerability: Adversary can permanently brick auctions due to precision error in Auction#_computeTotalRewards
Severity: high

Description:
When batch depositing to ProtocolRewards, the msg.value is expected to match the sum of the amounts array EXACTLY. The issue is that due to precision loss in Auction#_computeTotalRewards this call can be engineered to always revert which completely bricks the auction process.\\nProtocolRewards.sol#L55-L65\\n```\\n    for (uint256 i; i < numRecipients; ) {\\n        expectedTotalValue += amounts[i];\\n\\n        unchecked {\\n            ++i;\\n        }\\n    }\\n\\n    if (msg.value != expectedTotalValue) {\\n        revert INVALID_DEPOSIT();\\n    }\\n```\\n\\nWhen making a batch deposit the above method is called. As seen, the call with revert if the sum of amounts does not EXACTLY equal the msg.value.\\nAuction.sol#L474-L507\\n```\\n    uint256 totalBPS = _founderRewardBps + referralRewardsBPS + builderRewardsBPS;\\n\\n    // rest of code\\n\\n    // Calulate total rewards\\n    split.totalRewards = (_finalBidAmount * totalBPS) / BPS_PER_100_PERCENT;\\n\\n    // rest of code\\n\\n    // Initialize arrays\\n    split.recipients = new address[](arraySize);\\n    split.amounts = new uint256[](arraySize);\\n    split.reasons = new bytes4[](arraySize);\\n\\n    // Set builder reward\\n    split.recipients[0] = builderRecipient;\\n    split.amounts[0] = (_finalBidAmount * builderRewardsBPS) / BPS_PER_100_PERCENT;\\n\\n    // Set referral reward\\n    split.recipients[1] = _currentBidRefferal != address(0) ? _currentBidRefferal : builderRecipient;\\n    split.amounts[1] = (_finalBidAmount * referralRewardsBPS) / BPS_PER_100_PERCENT;\\n\\n    // Set founder reward if enabled\\n    if (hasFounderReward) {\\n        split.recipients[2] = founderReward.recipient;\\n        split.amounts[2] = (_finalBidAmount * _founderRewardBps) / BPS_PER_100_PERCENT;\\n    }\\n```\\n\\nThe sum of the percentages are used to determine the totalRewards. Meanwhile, the amounts are determined using the broken out percentages of each. This leads to unequal precision loss, which can cause totalRewards to be off by a single wei which cause the batch deposit to revert and the auction to be bricked. Take the following example:\\nAssume a referral reward of 5% (500) and a builder reward of 5% (500) for a total of 10% (1000). To brick the contract the adversary can engineer their bid with specific final digits. In this example, take a bid ending in 19.\\n```\\nsplit.totalRewards = (19 * 1,000) / 100,000 = 190,000 / 100,000 = 1\\n\\nsplit.amounts[0] = (19 * 500) / 100,000 = 95,000 / 100,000 = 0\\nsplit.amounts[1] = (19 * 500) / 100,000 = 95,000 / 100,000 = 0\\n```\\n\\nHere we can see that the sum of amounts is not equal to totalRewards and the batch deposit will revert.\\nAuction.sol#L270-L273\\n```\\nif (split.totalRewards != 0) {\\n    // Deposit rewards\\n    rewardsManager.depositBatch{ value: split.totalRewards }(split.recipients, split.amounts, split.reasons, "");\\n}\\n```\\n\\nThe depositBatch call is placed in the very important _settleAuction function. This results in auctions that are permanently broken and can never be settled.

Impact:
Auctions are completely bricked

Recommended mitigation:
Instead of setting totalRewards with the sum of the percentages, increment it by each fee calculated. This way they will always match no matter what.