EvolvingProteus::constructor() - During deployment of this contract the constructor will revert if the constants MAX_PRICE_VALUE and/or MIN_PRICE_VALUE are assigned to parameters `py_init` or `py_final` AND/OR `px_init` or `px_final` respectively, as valid & acceptable max/min values.
Audit: 2023-08-shell-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-08-shell/blob/8ed551004f470489e070c1dd617d67eb4bf114e6/src/proteus/EvolvingProteus.sol#L251-L252
https://github.com/code-423n4/2023-08-shell/blob/8ed551004f470489e070c1dd617d67eb4bf114e6/src/proteus/EvolvingProteus.sol#L166-L169
https://github.com/code-423n4/2023-08-shell/blob/8ed551004f470489e070c1dd617d67eb4bf114e6/src/proteus/EvolvingProteus.sol#L172-L175


# Vulnerability details

## Impact

(Note: This is not a known issue as per the following: "Failure when deploying a pool with incorrect prices".
Instead, my finding is about valid/correct prices, but still reverting deployment.)

EvolvingProteus::constructor() - During deployment of this contract the constructor will revert if the constants MAX_PRICE_VALUE and/or MIN_PRICE_VALUE are assigned to parameters `py_init` or `py_final` AND/OR `px_init` or `px_final` respectively, as valid & acceptable max/min values.

How many pool deployers would have run into this bug because they wanted to select MAX_PRICE_VALUE and/or MIN_PRICE_VALUE for the max/min prices for constructor parameters py or px init/final, but then deployment reverted, costing them loads of wasted gas? Maybe few, maybe many? Cant be sure.

So, I dont think this can be a high, and it could be a low, but medium risk logic bug is probably appropriate? 

Seems no funds at risk, except for deployer's lost funds on wasted deployment gas. 
Could have given users/deployers a negative impression/experience of the protocol, especially if they knew that MAX_PRICE_VALUE and MIN_PRICE_VALUE are valid values, but the deployment keeps reverting...and the error messages would be misleading in this case.

## Proof of Concept

Bug: Logic Error

```solidity
if (py_init >= MAX_PRICE_VALUE || py_final >= MAX_PRICE_VALUE) revert MaximumAllowedPriceExceeded();
if (px_init <= MIN_PRICE_VALUE || px_final <= MIN_PRICE_VALUE) revert MinimumAllowedPriceExceeded();
```
Assuming the dev comments for both MAX_PRICE_VALUE & MIN_PRICE_VALUE are correct(that these constants are the acceptable/valid max & min values that could be assigned to py & px initial & final prices), then the above `if` statements contain incorrect comparison checks. The error messages make it clear what the purpose of the `if` statements are, it's to prevent only invalid max/min values from being assigned. 
But constants MAX_PRICE_VALUE & MIN_PRICE_VALUE are VALID max & min values, not invalid.

So, since it's clear that the value of the constant MAX_PRICE_VALUE is the accepted MAX allowed price that can be used in the protocol for py_init or py_final, then the `=` in the `>=` comparison check would cause the exclusion of this valid allowed max price, because the constructor will revert. 
This is not intended functionality.
Same logic applies to the MIN_PRICE_VALUE for the px_init or px_final.

## Tools Used
VSC. Manual.

## Recommended Mitigation Steps

To keep the comparison checks in line with the intentions of the devs, the following