BabyPepe security record

In the contract `BabyPepe` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - call `claimStuckTokens()` to claim stuck tokens. - call `excludeFromFees()` to exclude accounts from fees - call `updateBuyFees()` to change buy fee - call `updateSellFees()` to change sell fee - call `updateWalletToWalletTransferFee()` to change transfer fee - call `changeMarketingWallet()` to change marketing wallet that receives marketing fee share - call `setSwapEnabled()` to enable the allocation of trade fees for: 1. add liquidity; 2. transfer to marketing wallet - call `excludeFromMaxWallet()` to manage accounts for the maximum wallet limit - call `excludeFromMaxTransactionLimit()` to manage accounts for the maximum transaction limit - call `setPair()`, `pairIsSet()`, `setSwapTokensAtAmount()`, `setEnableMaxWalletLimit()`, `setMaxWalletAmount()`, `setEnableMaxTransactionLimit()`, `setMaxTransactionAmounts()`, to set sensitive properties  In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. 

The contract contains two functions, `setPair()` and `enableTrading()`, that set the `uniswapV2Pair` address. The `setPair()` function updates the `uniswapV2Pair` only when the `pairSet` flag is false, ensuring that the pair cannot be modified afterward. However, the `enableTrading()` function also updates the `uniswapV2Pair` without checking the state of the `pairSet` flag. This discrepancy could lead to unintended changes to the `uniswapV2Pair`, potentially allowing for operational errors.

The contract includes functionality for charging transfer fees if `walletToWalletTransferFee` is nonzero when BabyPepe tokens are transferred between wallets. However, a potential issue arises when both `_totalFeesOnBuy` and `_totalFeesOnSell` are set to zero. In this scenario, the contract fails to trigger the `swapAndLiquify()` and `swapAndSendMarketing()` processes. Consequently, if the `walletToWalletTransferFee` is charged, but these processes are not triggered, the charged fee remains locked within the contract.