Overinflation in mint_bins() leads to incorrect storage accounting

The total_assets is incremented twice on the call to mint liquidity to a pool, thereby leading to the wrong evaluation of the total assets handled by the pool curve state.

The total_assets variable is used to keep track of the total amount of assets created and managed by the pool curve. The issue stems from when mint_bins() is called, during which shares are calculated and the LP token is to be minted.

let sub_id = next_lp_sub_id(storage_keys);
let lp_asset_id = _mint(
    storage_keys
        .total_assets,
    storage_keys
        .total_supply,
    to,
    sub_id,
    1,
);

The sub_id to be used for the new LP token is obtained via next_lp_sub_id(), where it increments the total_assets.

/// Gets the next LP sub ID
#[storage(read, write)]
pub fn next_lp_sub_id(storage_keys: MintStorageKeys) -> SubId {
    let total_assets = storage_keys.total_assets.read();
    let next_asset_id = total_assets + 1;
    //@audit increment as it is written to after the addition of the previous state with `1`
    storage_keys.total_assets.write(next_asset_id);

    next_asset_id.as_u256().as_b256()
}

But when calling _mint() it also writes to the total_assets, incrementing again if the LP token is being minted for the first time.

#[storage(read, write)]
pub fn _mint(
// .. snip ..
    // Only increment the number of assets minted by this contract if it hasn't been minted before.
    if supply.is_none() {
        total_assets_key.write(_total_assets(total_assets_key) + 1);
    }

This causes the total assets minted in storage to be double the amount that has actually been minted for the curve state.

total_assets is exposed externally and used by integrators as a reference for asset count. A double-incremented value misrepresents protocol state to anyone reading on-chain.

Remove the extra increment during the call to _mint().

Fixed in commit 584e378537207d8120da39e746e1da0293da5528.