Audit Fix L03: Blocking transactions using permit directly

Audit reference: `[FIL-1132b525-L03]`

There is an annoying griefing vector where the publiclly accessible EIP 2612 permit transmitted in a message to the network can be applied by a griefing 3rd party to credit the payments contract with the permitted allowance *before* the users' intended message lands on the contract. Because we don't try catch the permitting function this will cause an annoying failure for the user's message forcing them to go back and deposit with the unpermitted version.

To be clear the user gets exactly what they want in the griefing scenario from POV of system state. However they have to do an annoying UX retry because payments contract isn't smart enough to handle it for them. We should go with audit recommendation

> Wrap the permit call in a try-catch block to handle permit failures gracefully. If the permit fails, check the approval. If approval is sufficient, proceed with the deposit.

Locate the payments contract's EIP-2612 permit and deposit entry points, then read how allowance and permit failures are currently handled. The work is done when a failed permit no longer blocks a deposit if the existing allowance is sufficient, with tests covering both successful and griefed permit scenarios.

Written by the indexing model from the issue text.