The corrected encoder is committed, but the premise needs correcting: the failed transaction has three encoding bugs, not one, and the suspected 2^128-1 amount is not what reverted it.

With all three fixed, the calldata executes in simulation against the live router; nothing was broadcast. With that transaction's parameters, the encoder reproduces the successful transaction's input byte for byte.

The three bugs

Both transactions use actions 0x060c0e. The failed one differs in the params of two actions:

1. Missing struct offset. The router reads the first word as the struct's offset; your encoder laid the fields out flat.
2. Struct one word short. This router has an extra field between amountOutMinimum and hookData: a per-hop minimum price, where 0 means off. Without it the params fall below the router's minimum length. This is the revert your transaction hit: SliceOutOfBounds() (0x3b99b53d).
3. Wrong TAKE shape. 0x0e takes three words; you sent the two-word shape that belongs to 0x0f.

I tried all eight combinations of these fixes against the live router; only the one with all three executes.

The 2^128-1 suspect

The successful transaction has no second swap (its commands are 0x10), so it cannot show what a second swap's amount should be. It does show that OPEN_DELTA on this router is 0: its take amount is 0 and the router paid out the whole credit.

• 2^128-1 is taken literally. The router sells PONS until the pool hits its price floor, then pulls that from your wallet. On the 2500/25 pool this succeeded in simulation, selling 0.61 PONS for 0.115 USDG. The encoder now refuses this value.
• 0 reverts with SwapAmountCannotBeZero() when swap 2 is its own command, because a credit cannot carry from one V4_SWAP command to the next.

So buildCalldata() takes one fixed ponsAmount and uses it as swap 1's minimum output and swap 2's exact input. I also added buildAtomicCalldata(), which you did not ask for: both swaps in one command (0x06060e), where amountIn = 0 really does mean "sell what swap 1 bought". It needs no Permit2 allowance and only settles if the round trip at least breaks even.

What will still stop the transaction

• Permit2 allowance: the failed transaction's sender has no Permit2 allowance to the router for USDG or PONS. The corrected calldata reverts with AllowanceExpired(0) until that is granted.
• Decimals: USDG has 6 decimals. Your transaction sold 1e16 units, which is 10 billion USDG; 0.01 USDG is 10000.
• Pools: the failed transaction used fee 2500 / tick spacing 25 for both swaps, not the two pools in the brief.
• Pool B is empty: the 30000/600 pool had no liquidity when I checked. Selling PONS into it returned 0 USDG, so with a zero minimum you end up holding PONS.
• No profit on that route: A then the 2500/25 pool returned about 9,710 to 9,910 units for 10,000 in.

Limits of the verification

• Blockscout answered with a browser challenge, so both calldatas came from the RPC in the brief.
• The router's source could not be read, so the extra field's name (minHopPriceX36) is inferred from its revert selector and behaviour.
• I did not have your HTML file, so the function signatures are mine and your call sites need adapting.
• forge build, forge test (37 tests, with the verifier's seed) and forge fmt --check pass; the JavaScript test passes 18 cases. Slither was not run.

The deliverable is js/v4-arb-encoder.js; README.md has the usage, assumptions and operational responsibilities.