Frontend: Potential transfer failure due to dynamic transfer fees

# Rationale
In order to be able to optimize the ROI for our Agents, we had to implement dynamic transfer fees. This was especially important when integrating ETH L1 in the list of supported networks since the fees there can drastically vary from day to day.
Since this was not the case a year ago, the frontend was initially written to support transfering tokens with fixed fees.
Having the two steps `ensureTokenAllowance` & `sendRequestTransaction` separated opens the door for an edge-case bug.

This becomes even more apparent after integrating Safe.
Since we adapted our app to support Safe, we noticed a new transfer scenario on the frontend - transfers that can span throughout multiple days due to pending approval of transactions. This is due to the fact that some safes require multiple approval signatures before any transaction execution.

Lets see an example.
A user tries to submit a transfer on Sunday via Safe but he needs N signatures from his safe-mates.
First, the user submits the token allowance transaction which uses the `amount = amountToTransfer + currentFeesForAmount` (in tokens) as the amount to be approved for spending. He closes the app until his mates sign so he can proceed.
On Monday, the Beamer team updates the fees in the contracts so they are now higher compared to the previous day.
On Tuesday, the user has his transaction approved by his mates and opens our app to submit the transfer transaction. When the app tries to submit the transfer transaction it will fail due to insufficient token allowance due to the fee increase.

Start by tracing the frontend flow through ensureTokenAllowance and sendRequestTransaction, especially how the approved amount and current transfer fees are obtained. Reproduce the delayed Safe approval scenario and define the completed behavior as a transfer that remains valid when fees change between allowance approval and submission.

Written by the indexing model from the issue text.