The logic behind hardcoding `MAX_TWAP_DELTA_LIQUIDATION` is quite flawed and directly allows distressed accounts to sidestep being liquidated as they can hold on to bad debts for longer
Audit: 2024-04-panoptic-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticPool.sol#L156-L158


# Vulnerability details


## Proof of Concept

First take a look at https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticPool.sol#L156-L158

```solidity

    int256 internal constant MAX_TWAP_DELTA_LIQUIDATION = 513;

```

We can see that there is a hardcoded implementation of the maximum amount of allowed difference between the `currentTick` and the Uniswap's `TWAP tick`, would be important to note that the only instance where this is used is whenever liquidations are to occur, i.e https://github.com/code-423n4/2024-04-panoptic/blob/833312ebd600665b577fbd9c03ffa0daf250ed24/contracts/PanopticPool.sol#L156-L160

```solidity
    function liquidate(
        TokenId[] calldata positionIdListLiquidator,
        address liquidatee,
        LeftRightUnsigned delegations,
        TokenId[] calldata positionIdList
    ) external {
        _validatePositionList(liquidatee, positionIdList, 0);

        // Assert the account we are liquidating is actually insolvent
        int24 twapTick = getUniV3TWAP();

        LeftRightUnsigned tokenData0;
        LeftRightUnsigned tokenData1;
        LeftRightSigned premia;
        {
            (, int24 currentTick, , , , , ) = s_univ3pool.slot0();

            // Enforce maximum delta between TWAP and currentTick to prevent extreme price manipulation
            //@audit
            if (Math.abs(currentTick - twapTick) > MAX_TWAP_DELTA_LIQUIDATION)
                revert Errors.StaleTWAP();
        //(...snip)

        emit AccountLiquidated(msg.sender, liquidatee, bonusAmounts);
    }

```

Issue with the current implementation is that the idea of hardcoding `MAX_TWAP_DELTA_LIQUIDATION` is heavily flawed as to different instances different volatility, as such this could cause heavy reversions in case where they shouldn't be a revert, that's to say on attempts to liquidations of distressed accounts, even if the position is **heavily underwater** the STALE TWAP price check would cause the attempt on liquidating to revert, cause the protocol would assume there is a price manipulation going on, which then allows the distressed account to hold on to the bad position for even longer, allowing accumulation of bad debt as the position continues to drop in value (which is not uncommon in the crypto world).

Keep in mind that the absolute difference between `currentTick` and the `twapTick` is being taken, i.e even if the current price from `slot0` is very low indicating position is heavily underwater the check still reverts, which completely flaws protocol's assumption from this comment `"// Enforce maximum delta between TWAP and currentTick to prevent extreme price manipulation" `, cause in this case the prices were not manipulated but rather the asset dropped in value, by just navigating to any reliable oracle/price provi