🐛 Apply max fee overhead to privacy pool fee - #72

PR #72 applied `max_fee_multiplier` (~3x) to the pool fee, which caused
users to approve triple the amount they actually owed and hit
"Insufficient ERC20 balance" on execute.

The pool fee is a fixed amount in STRK read from the pool, so it does not
need the large safety multiplier that guards against gas-fee volatility —
only a small overhead to cover STRK / gas-token price drift between build
and execute. Use `compute_paid_fee_in_strk` (~1.1x via `provider_fee_overhead`)
for the pool portion; keep `compute_max_fee_in_strk` on the gas portion.

PR #72 applied `max_fee_multiplier` (~3x) to the pool fee, which caused
users to approve triple the amount they actually owed and hit
"Insufficient ERC20 balance" on execute.

The pool fee is a fixed amount in STRK read from the pool, so it does not
need the large safety multiplier that guards against gas-fee volatility —
only a small overhead to cover STRK / gas-token price drift between build
and execute. Use `compute_paid_fee_in_strk` (~1.1x via `provider_fee_overhead`)
for the pool portion; keep `compute_max_fee_in_strk` on the gas portion.

PR #72 applied `max_fee_multiplier` (~3x) to the pool fee, which caused
users to approve triple the amount they actually owed and hit
"Insufficient ERC20 balance" on execute.

The pool fee is a fixed amount in STRK read from the pool, so it does not
need the large safety multiplier that guards against gas-fee volatility —
only a small overhead to cover STRK / gas-token price drift between build
and execute. Use `compute_paid_fee_in_strk` (~1.1x via `provider_fee_overhead`)
for the pool portion; keep `compute_max_fee_in_strk` on the gas portion.

* Approve privacy pool to pull STRK fee in forwarder

The last call of a private batch targets a privacy pool whose `apply_actions`
collects its fee via `transferFrom(forwarder, fee_collector, fee)` on STRK,
independent of the user's gas token. Without an allowance, that transfer
reverts on the ERC20 check.

- Add `IPrivacyPool` dispatcher (`get_fee_amount`) and a 10_000 STRK safety cap.
- Hardcode the canonical STRK address on Starknet; `approve_pool_fee` always
  approves the pool on STRK, never on the user's gas token.
- Wire the helper into `execute_private` and `execute_private_sponsored`.
- Add a minimal `MockPrivacyPool` and tests covering the fee-limit guard.

* Apply only provider overhead to the privacy pool fee

PR #72 applied `max_fee_multiplier` (~3x) to the pool fee, which caused
users to approve triple the amount they actually owed and hit
"Insufficient ERC20 balance" on execute.

The pool fee is a fixed amount in STRK read from the pool, so it does not
need the large safety multiplier that guards against gas-fee volatility —
only a small overhead to cover STRK / gas-token price drift between build
and execute. Use `compute_paid_fee_in_strk` (~1.1x via `provider_fee_overhead`)
for the pool portion; keep `compute_max_fee_in_strk` on the gas portion.

* Pre-fund forwarder with STRK from relayer for privacy pool fee

The privacy pool collects its fee via `transferFrom(forwarder, fee_collector, fee)`
in STRK. When the user pays in a non-STRK gas token (USDC, etc.), the forwarder
has no STRK balance for the pool to pull, so `apply_actions` reverts.

The relayer already holds STRK (refilled by the gas-tank → relayers rebalancing),
so we prepend a `strk.transfer(forwarder, pool_fee_amount)` call before the
forwarder call in both private and private-sponsored flows. The relayer is
reimbursed when the forwarder forwards the user's gas-token payment to the gas
tank, closing the loop via the existing rebalancing.

Only emitted when `privacy_pool_fee_amount > 0`, so non-pool-fee transactions
are unchanged.