Kodiak swap functions do not check if output token is approved, risking stuck assets

Inch_Module swap functions (inch_swap, inch_uniswapV3Swap, inch_clipperSwap) validate that both the input and output tokens are in the strategy's allow-list before executing a swap.

However, this validation is missing in Bera_Module::bera_kodiakv2_swap and Bera_Module::bera_kodiakv3_swap. Only the input token is validated; the path's destination token is not checked at all.

As a result, the trader (EXECUTOR_ROLE) can swap into a non-approved token by encoding it as the path's terminal hop. Once held by the strategy, that token cannot be swapped back because the reverse direction would fail input-token validation (the same swap functions reject non-approved input tokens). The token sits in the strategy permanently, locking the assets.

The audit included a Foundry PoC (test_bera_kodiakv2_swap_to_non_allowed_token) that swaps to a non-approved token, then proves the reverse swap reverts with "Invalid token".

• If a trader swaps into a non-approved token, the resulting balance is irreversibly stuck in the strategy.
• Whether intentional (a compromised or malicious trader exfiltrates value into a long-tail token they can liquidate elsewhere) or accidental (a misconfigured path), the asset is unrecoverable.

Validate both the input and the output token, mirroring the pattern used in Inch_Module. For Kodiak V2 the output is the last address in the address[] path; for Kodiak V3 the output is the last 20 bytes of the encoded path bytes.

D2: Fixed in c70268c.

Cyfrin: Verified.