Fixed unfinished TODOs

[mts1715]

Closes #110

Summary

• Implement graceful failure recovery in ERC4626SinkConnectors.AssetSink when EVM approve/deposit calls fail
• Add tokenSource for bridging assets back from EVM on recovery
• Add proper documentation for swap() and swapBack() methods in ERC4626SwapConnectors
• Add validation for feeSource (must provide FlowToken) and underlying asset matching

Changes

ERC4626SinkConnectors.cdc

• Added tokenSource: EVMTokenConnectors.Source for failure recovery
• Updated COA capability to include EVM.Bridge entitlement
• Implemented recovery on approve() failure (bridge tokens back)
• Implemented recovery on deposit() failure (revoke approval, bridge tokens back)
• Replaced TODO comments with proper implementation

ERC4626SwapConnectors.cdc

• Added @param and @return documentation for swap() and swapBack()

Tests

• New test testDepositToPausedVaultRecoversGracefully verifying recovery behavior
• New transaction deposit_to_paused_vault.cdc for testing paused vault scenarios
• Updated test helpers with access control facet deployment

[zhangchiqing]

   /// If unsuccessful (no tokens recovered), destroys the empty vault and returns false.

Are we sure the recovered is empty here? I think withdrawAvailable will return a partial balance like (50 tokens when asked for 100), if it fails the check above, and then we will burn these 50 tokens. Do we want to deposit back anyway, and return true or false depending on whether the amount is full or partial ?

[mts1715]

fix: withdraw to receiver available up to amount.
Returns true if the full amount was recovered (within rounding tolerance), false if only partial or zero.

1f4cb11