UI bugs in multicall

Two bugs found recently in multicall setup.
loss of funds / bad trade can happen.
naturally this has occurred with problematic pools/tokens, but a simple addition to multicall could save people

First Bug Description
most recent one
loss of ETH
https://etherscan.io/tx/0xbda60615c76ef1c8bd3051f86489c0348541f16b995952387e63227228b500a5
Launch of a reflection token on V3 caused many issues with sqrtPriceX96
plenty of liquidity was/is in the pool, but trades kept breaking price

The call to exactInputSingle in the router calls the pools swap with amount in with Eth being sent with tx to router, the loops steps through the pool for best price for that trade, and then the pool does the calls for transferring the amount after in the callback, and the pay() pays the amount required.
when the amount required is less than the ETH in the contract, the pay function only wraps and sends the requested WETH. The UI doesn't wrap the call with a refundETH so remaining ETH is left in the router.

Expected Behavior
adding refundETH() call to the multicall for ETH swaps would solve with little cost is gas

Second Bug Description
Also right now when the UI calls the new router V2 pool and the swapTokensForExactTokens has no safety check for making sure the Exact tokens show up. so if a token has a FOT which the getAmountsIn can’t tell, then you lose that fee in the trade with the slippage having little effect. I figured out a way to fix it (at least for UI calls) having the swapTokensForExactTokens Use address.this (therefore returning tokens to router) then calling sweepTokens with a minimum tokens out, should solve this, since the tx would fail if contract didn't have the min.
Here is a very bad tx due to a very bad Token Fee of 75% https://etherscan.io/tx/0x6aadaad9ced3505770482725cb043da06fed3515df1147d085b7cf438080a155/advanced user had a 10% slippage tx sent .46 ETH returned .042 ETH (for the 10% difference) expected out was 90,270,400.000000000 and only received 22,567,600.000000000 naturally this is due to a bad token with a high fee, but tx didn't revert due to the loss.
Slippage would be a little odd with this solution since you need the upper slippage for volume, but it should only be affected by the FOT tokens, but with the min out being equal to TokenOut – slippage FOT tokens slippage could go up to double slippage (depending on fee and volume).

Expected Behavior
adding a minimum out via the sweepTokens() function would solve, issue being the choice of where the slippage percentage comes into play, With the incoming ETH is needed, but separate slippage doesn't make sense. My best thoughts is split it 50/50 of current price.

Start by tracing the interface's multicall setup and the router calls named in the report: refundETH(), swapTokensForExactTokens, and sweepTokens(). Reproduce the linked transactions or equivalent problematic-token swaps, then define and test behavior that prevents leftover ETH and rejects insufficient fee-on-transfer output while resolving the proposed slippage treatment.