toLock which is the amount of shares (MYT) needed for debt amount is added into _totalLocked .
notice that this value toLock is recalculated using convertDebtTokensToYield which if the VaultV2 accruing yield, the same amount at timestamp X would result different share if done at timestamp X + Y where the yield accrued.
this ultimately create discrepancy in the real _totalLocked, because how it is updated only with toLock which after many subsequent deposit it would became inflated/innacurate.
example: at timestamp X, the asset per share is 1:1, user mint 100 debt token which need 111 MYT as collateral. 111 MYT is added to _totalLocked. account.rawLocked is 111 MYT.
at timestamp X+Y, the asset per share is 1:0.9, user mint 100 debt token which need only 99.9 MYT collateral. 99.9 MYT is added to _totalLocked . now _totalLocked is 111 MYT + 99.9 MYT = 210.9 MYT.
notice the account.rawLocked is each time recalculate the lockedCollateral + toLock using latest value per share which is now respectively: 99.9 MYT and the new debt requires 99.9 MYT to lock, for a new total of 199.8 MYT.
this discrepancy itself already sufficient for a bug. but we can further check where the additional impact is:
when redeem happening, the _collateralWeight would be calculated using the _totalLocked and totalOut . now we know that _totalLocked is inflated, this means the _collateralWeight would be inaccurate and affect all users.
Impact Details
_totalLocked would be inflated over time which later would severely affect how the _collateralWeight is calculated. potentially to an artificially low or "stunted" _collateralWeight over time.
