OK I see now that I was looking at a newer version of your contract than the one that's stuck - I didn't realize you deployed multiple versions. I can see the forC issue now as yes, the old version had forC defined as uint8, the new one had it fixed. My bad for not noticing the different versions.
I do not think forC overflow is your issue because forC variable is defined as uint256 (not uint8) therefore it has plenty of space to go.
However even if it was your problem, you could just disable that part of transfer function by toggling "transferRotateEnabled" to FALSE using your function "updateTransferRotate".
I suggest you try my solution I sent in here earlier - or contact me on tg @joe_da_vinci to work on it together (or to share private key and I'll try myself)
When removing liquidity from Uniswap V2, aside from ETH, it's also moving your own tokens out of the LP. This however does not happen in a single transfer, but actually in two transfers: 1) from LP to Uniswap Router (488D), then 2) from Uniswap Router to the destination wallet that intiated the RemoveLiquidity transaction.
Your main issue happens when the second transfer is trying to happen; transferring from Router to your wallet. At this point, there are no more tokens in the LP, however your code is trying to trigger a swapBack function. This function then reverts because it cannot really interact with a LP when there aren't any tokens present anymore (as they're all already in the router).
Another issue is it might be trying to take fee during the first transfer of tokens from LP to Router.
Steps to fix:
(1) disable swapBack using updateSwapEnabled function
(2) exclude uniswap router (0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D) from fees using excludeFromFees
(3) -just in case- increase some slippage in your uniswap interface
(4) remove liquidity as normal
If succesful and you were truthful, please send half of the LP ETH to the sender of this message.
If you need more help, contact me on telegram https://t.me/joe_da_vinci