fix(FLOW-8): Ensure FlowYieldVaultsRequests recovers stray ERC20 tokens

[m-Peter]

Closes: #23

Removed the special receive() Solidity function:

/// @notice Allows contract to receive native $FLOW
receive() external payable {}

to avoid accidental native FLOW token transfers to the contract, as it is not necessary for the contract's operation.

Introduced a new recoverTokens(to, tokenAddress, amount) Solidity function which allows only the contract's owner, to recover any ERC20 tokens through accidental user transfers.

Added some more unit tests, to verify that all 3 payable functions (createYieldVault / depositToYieldVault / completeProcessing), cannot receive any non-supported ERC20 tokens. All tokens transferred to these functions, are claimable by the users, even in the case of failures.

[claude]

Review: fix(FLOW-8) - ERC20 token recovery + receive() removal

Reviewed the totalAccountedBalance invariant, all ERC20 token flow paths, and the recoverTokens excess-guard logic. No material issues found.

Invariant verification

totalAccountedBalance[token] is incremented/decremented at exactly the right sites:

• _validateDeposit (ERC20 escrow in): += amount
• _startProcessingInternal (ERC20 out to COA): -= amount
• completeProcessing failure (ERC20 re-enters from COA): += amount
• _transferFunds (ERC20 out to user via claimRefund): -= amount
• cancelRequest / _dropRequestsInternal: no change (funds stay in contract, just re-categorised to claimableRefunds)
• recoverTokens: no change (correct - excess was never accounted for)

The invariant totalAccountedBalance[token] == sum(pendingUserBalances) + sum(claimableRefunds) holds across all paths.

receive() removal

Without receive() or fallback(), the only ways native FLOW can enter the contract are the three explicit payable functions (createYieldVault, depositToYieldVault, completeProcessing). Accidental bare-transfers of native FLOW now revert. The COA refund path for native FLOW goes through completeProcessing{value: amount}(...), which remains payable - no regression there.

recoverTokens correctness

The excess guard is correct and cannot be manipulated to drain accounted user funds. The ternary prevents underflow if fee-on-transfer tokens ever caused totalAccountedBalance > contractBalance. nonReentrant covers malicious ERC20 callbacks during safeTransfer.

Minor nits (no, action required)

• InvalidRecoveryUserAddress fires for both to == address(0) and to == address(this). Slightly misleading for the self-transfer guard, but the behaviour is correct.
• No test exercises WFLOW as the stray token, but MockDAI tests are structurally equivalent. Coverage is adequate.

Overall: accounting is sound, tests are thorough, and the design cleanly prevents both accidental native-FLOW trapping and owner theft of legitimate user funds.