fix: a step the router lets fail is marked and sets no minimum (closes #602)

Each Universal Router release now carries the command types its dispatch()
can return a failure for instead of reverting, read from its source; only a
step of one of those with the allow-revert flag (0x80) set can fail while the
transaction goes on. Such a step is listed with "(allowed to fail)". A minimum
such a step states guarantees nothing, so it is read as zero: a
BALANCE_CHECK_ERC20 then keeps an earlier step's minimum, and 0x10 on
UniversalRouterV1 and UniversalRouterV1_2_V2Support, an NFT call there still
read as a V4 swap, states no minimum. Every swap and every payment of ETH or an
ERC-20 token succeeds or reverts the whole transaction, so the flag on them has
no effect.

Model: opus-5-5

README.md

@@ -1198,7 +1198,11 @@ number. They can read:
   guarantees nothing: it sets `Token Out` and `Min. received` only when the
   output side holds no minimum, not even a zero one, at the point the check is
   reached, and otherwise leaves the current token and figure in place. A nonzero
-  `minBalance` sets both lines, as a swap step does.
+  `minBalance` sets both lines, as a swap step does. A `BALANCE_CHECK_ERC20`
+  step that the router lets fail without reverting the transaction (see
+  Transaction Decoding) guarantees nothing either, whatever its `minBalance`,
+  and is read as one whose `minBalance` is zero. A minimum stated by a V4 swap
+  step the router lets fail is likewise read as zero.
 
 The swap's `Token In` and `Token Out` lines name a currency, not an amount; each
 reads `Unknown (not named in the calldata)` when the decoder found no token for
@@ -2970,13 +2974,33 @@ Currently supported:
   address uses: `0x1f` for `UniversalRouterV1`, `0x3f` for
   `UniversalRouterV1_2_V2Support` and `UniversalRouterV2`, and `0x7f` for
   `UniversalRouterV2_1_1` and `UniversalRouterV2_1_2`. The allow-revert flag
-  (`0x80`) therefore does not change a step's name. Only the routers with the
-  `0x7f` mask have `PAY_PORTION_FULL_PRECISION` (`0x07`), listed as
-  `Pay Portion (Full Precision)`, and `ACROSS_V4_DEPOSIT_V3` (`0x40`), listed as
-  `Across Bridge Deposit`; the other routers revert on `0x07`, and it is listed
-  there as `Command 0x07`. The decoder does not read the commands inside an
-  `EXECUTE_SUB_PLAN` (`0x21`) step, and wherever that step stands they may spend
-  the user's tokens or pay the user. That step is listed as
+  (`0x80`) therefore does not change the command a step is read as. The router
+  reverts the whole transaction when a step fails, unless the step's command
+  byte has that flag set and its command is one the router lets fail, as each
+  release's `contracts/base/Dispatcher.sol` shows: on `UniversalRouterV2`,
+  `UniversalRouterV2_1_1` and `UniversalRouterV2_1_2`, `PERMIT2_PERMIT`,
+  `PERMIT2_PERMIT_BATCH`, `BALANCE_CHECK_ERC20`, `V3_POSITION_MANAGER_PERMIT`,
+  `V3_POSITION_MANAGER_CALL`, `V4_INITIALIZE_POOL`, `V4_POSITION_MANAGER_CALL`
+  and `EXECUTE_SUB_PLAN`; on `UniversalRouterV1_2_V2Support`,
+  `BALANCE_CHECK_ERC20`, `EXECUTE_SUB_PLAN` and its NFT market calls and NFT
+  owner checks; on `UniversalRouterV1`, its NFT market calls and NFT owner
+  checks. Such a step may then fail while the transaction goes on to the next
+  step, and it is listed with ` (allowed to fail)` after its name, for example
+  `Balance Check (allowed to fail)`. On every other command, among them each V2,
+  V3 and V4 swap and each payment of ETH or an ERC-20 token, the flag has no
+  effect: the step succeeds or the whole transaction reverts, so the step reads
+  as it does without the flag. A `BALANCE_CHECK_ERC20` the router lets fail
+  guarantees nothing, so it is read as one whose `minBalance` is zero. On
+  `UniversalRouterV1` and `UniversalRouterV1_2_V2Support`, `0x10` is an NFT
+  market call the router lets fail, which the decoder still reads as a V4 swap
+  ([#592](https://git.eeqj.de/sneak/AutistMask/issues/592)); with the flag set,
+  a minimum it states is read as zero: `None (no minimum guaranteed)`. Only the
+  routers with the `0x7f` mask have `PAY_PORTION_FULL_PRECISION` (`0x07`),
+  listed as `Pay Portion (Full Precision)`, and `ACROSS_V4_DEPOSIT_V3` (`0x40`),
+  listed as `Across Bridge Deposit`; the other routers revert on `0x07`, and it
+  is listed there as `Command 0x07`. The decoder does not read the commands
+  inside an `EXECUTE_SUB_PLAN` (`0x21`) step, and wherever that step stands they
+  may spend the user's tokens or pay the user. That step is listed as
   `Execute Sub-Plan (its steps are not shown)`, and whatever the other steps
   state, the summary names no swap direction, `Token In` and `Token Out` read
   `Unknown (could not be decoded)`, and there is no `Amount` or `Min. received`