The discrepency in `issuancePremium` accounting, during the `issuance of RTokens` and the `available basket units` calculation in the `BackingManager`, could lead to an `incorrect assessment` of the `collateralization status`
Audit: 2024-07-reserve-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/RToken.sol#L139-L143
https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/BasketHandler.sol#L499-L504
https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/BackingManager.sol#L124
https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/BasketHandler.sol#L620-L626
https://github.com/code-423n4/2024-07-reserve/blob/main/contracts/p1/BackingManager.sol#L132


# Vulnerability details

## Impact

There is a discrepancy between the calculation of the `required collateral tokens` during `issuance of RToken` (which includes the issuancePremium) and the calculation of the `available basket units` held by the `BackingManager` (which does not account for the issuancePremium).

During a depeg scenario, when the `RToken.issueTo` function is executed, the `BasketHandler.quote` function is called with `applyIssuancePremium` set to true. This ensures that the `required collateral token quantities` are `adjusted` to account for the `issuance premium`, effectively requiring more collateral tokens to be transferred to the `BackingManager` contract. The following code snippet from `BasketHandler.quote` depicts this scenario:

```solidity
            if (applyIssuancePremium) {
                uint192 premium = issuancePremium(coll); // {1} always CEIL by definition

                // {tok} = {tok} * {1}
                if (premium > FIX_ONE) q = q.safeMul(premium, rounding);
            }
```

However, when the `BackingManager.rebalance` function is executed, the `BasketHandler.basketsHeldBy` function is called to determine the `number of basket units` held by the `BackingManager`. This function directly uses the calculated token quantity per basket unit and `does not apply the issuancePremium` to calculate the `available basket units` as shown below:

```solidity
            uint192 q = _quantity(basket.erc20s[i], coll, CEIL); //@audit-info - token quantity per basket unit is rounded up
            if (q == FIX_MAX) return BasketRange(FIX_ZERO, FIX_MAX); //@audit-info - (bottom, top)

            // {BU} = {tok} / {tok/BU}
            uint192 inBUs = coll.bal(account).div(q); //@audit-info - basket unit amount is rounded down
            baskets.bottom = fixMin(baskets.bottom, inBUs);
            baskets.top = fixMax(baskets.top, inBUs);
```

This discrepancy can lead to a situation where the `basketsHeld.bottom` value (the number of whole basket units held by the BackingManager) is `overestimated` because `it does not account` for the `additional collateral tokens required due to the issuance premium`.

Consequently, the following condition in the `BackingManager.rebalance` function may incorrectly evaluate to true, even though the `BackingManager does not hold enough collateral tokens` to fulfill the `basketsNeeded` value after considering the issuance premium:

```solidity
    if (basketsHeld.bottom >= rToken.basketsNeeded()) return;