fix(R-I-07,R-I-08): enforce a non-zero minimum fundsIn amount; zero-amount fundsOut guard

[sh3ifu]

R-I-07 + R-I-08 — zero-amount and dust deposits

Closes two related findings with one coherent change on the inbound path.

• R-I-07 (zero-amount): fundsIn/fundsOut accepted amount == 0, a no-op
  that only emitted redundant events.
• R-I-08 (dust): deposits small enough that amount * stablePercent / multiplier^2 floors to zero bridged with no commission (event/processing noise).

Change

• minFundsInAmount — constructor arg + onlyOwner setMinFundsInAmount.
  Validated non-zero at both the constructor and the setter
  (InvalidMinFundsInAmount). A non-zero floor is the single invariant that
  closes both findings on the inbound path. Units: token smallest units
  (USDT0 = 6 decimals).
• fundsIn — one check: amount < minFundsInAmount → AmountBelowMinimum.
  Since the floor is always non-zero, zero-amount deposits revert here too, so
  R-I-07 stays closed regardless of config.
• fundsOut — amount == 0 → ZeroAmount only. No minimum: it is an
  authorized release of an already-recorded amount (incl. residual partial
  consumes from RgbSettlementModule), and a floor could block legitimate small
  releases.

Governance

setMinFundsInAmount is onlyOwner (owner = MultisigProxy). The federation
retunes it through the existing generic proposeAdminExecute → timelock →
executeProposal flow — no MultisigProxy changes, no new EIP-712 typehash.