feat: invariants and tests

[simon-something]

Invariants tested:

• total disbursed fees should always be equal to the sum of the vault balances before disbursement - this is the main invariant, as it eliminate: dust somewhere in the flow, "partial" vault withdrawals (eg one vault not transferring its balance as intended), wrong recipient, etc
• no dust accumulation in the FeeSplitter
• disburseFees can only revert if either one of the vault has a balance below it's minimum withdrawal amount or if the disbursement interval has not been reached yet

The share computation isn't tested here, at it would be a copy-paste of the existing fuzzed unit test (perhaps we could increase the fuzz runs for testFuzz_getRecipientsAndAmounts_succeeds, even though it's tightly coupled to the implementation anyway).

To run these efficiently, set corpus_dir = "corpus" in the foundry.toml (it can be run with fail_on_revert too, as revert cases are tested).

[0xDiscotech]

Looking good so far! I'd like to ask coverage on the following branches/cases:

• Could we add a setter updating the minWithdrawalAmount threshold? We are way more interested on testing the 0 amount scenario than anything else, but we still need to cover other branches or paths.

• Could we add also tests checking that L1Withdrawer withdraws when the threshold is reached, and that FeesDepositor initiates the deposit when the threshold is reached as well? No strictly needed if you don't find any invariant matching this test, but I think it'd be good to cover that integration as well.

[simon-something]

Looking good so far! I'd like to ask coverage on the following branches/cases:

• Could we add a setter updating the minWithdrawalAmount threshold? We are way more interested on testing the 0 amount scenario than anything else, but we still need to cover other branches or paths.

Choure fing!

• Could we add also tests checking that L1Withdrawer withdraws when the threshold is reached, and that FeesDepositor initiates the deposit when the threshold is reached as well? No strictly needed if you don't find any invariant matching this test, but I think it'd be good to cover that integration as well.

For the L1Withdrawer, it's already used (hence the L2toL1 balance included in the token conservation), but will add more granular test to make sure it get triggered on threshold (I saw it in the trace, but that doesn't count;)
Will add FeesDepositor too, shouldn't be a big lift

[0xDiscotech]

LGTM!