Eliminate persistent Set allowances and residual balances

[stxphxn]

Summary

• force-approve exact Set pool allowances for zero-first tokens and clear them immediately after successful pool calls
• enforce call-scoped ERC-20 input balance snapshots so fee-on-transfer assets and pools that under-consume input revert atomically
• prevent token and pool reentrancy across Set execution while preserving sequential multicall legs
• add unit and stateful invariant coverage for success, revert, reentrancy, malicious pools, false returns, native modes, and arbitrary multicall sequences
• document the hardened Set execution safety model while retaining internal pool / poolId terminology

Why

The existing direct execution path cleared allowances on the normal path, but it did not handle USDT-style zero-first approvals or explicitly prove that the router input balance returned to its pre-call snapshot. A malicious pool could under-consume an approved input, and taxed assets were rejected only incidentally. The execution entry point also lacked an explicit reentrancy guard.

Impact

Successful direct swaps leave no call-scoped token or native residue and no Set pool allowance. Pre-existing router balances are excluded from settlement accounting. Unsupported fee-on-transfer and false-returning behavior reverts atomically.

Validation

• npm run check
  • root tests: 116 passed, 1 skipped
  • quote service tests: 205 passed
  • app tests: 59 passed
  • upstream zFi Foundry tests: 95 passed
  • local contract tests: 156 passed
  • invariant suite: 256 runs / 128,000 calls per invariant
  • lint, type-check, formatting, deployment verification, and bytecode-size gates passed
• npm run build
• focused Set execution suite: 49 passed

Closes #14