Update EIP-8141: atomic-batch unroll rolls back the approval context

[Marchhill]

Summary

Pins down what happens to the transaction-scoped approval context (payer, sender_approved) when the frame that modified it is discarded — on an individual frame revert and on an atomic-batch unroll.

Problem

ethereum#11955 settled the VERIFY case: "If the frame reverts, the transaction is invalid. This would unroll any effects of APPROVE." The batch-unroll rule, however, only says the state "must be rolled back to the condition it was immediately before the atomic batch began" and is silent on the approval context, which the spec defines as transaction-scoped variables distinct from state.

The combination is reachable: approval-scope flags are valid with any mode, and the batch constraints only exclude VERIFY frames, so a DEFAULT or SENDER frame inside a batch may carry APPROVE_PAYMENT scope and its target's code may call APPROVE(APPROVE_PAYMENT) (once sender_approved is true). If a later frame in the batch then fails, the nonce increment and max_cost collection are state changes and roll back with the batch — but whether payer stays set is undefined. If it did stay set, fee settlement would return payer_refund to a payer whose max_cost collection was rolled back, and the sender nonce would remain unconsumed: an unintended value-creation and replay path.

Fix

Apply the direction the spec already took for VERIFY reverts (ethereum#11955) and for the transaction-scoped refund_counter (whose changes "by a reverted frame, or by frames unrolled as part of a failed atomic batch, are discarded together with that frame's state changes"): approval-context changes are discarded whenever the frame that made them is discarded.

• Frame revert: one sentence stating that a reverted frame's approval-context changes are discarded with its state changes.
• Batch unroll: one bullet stating that the approval context is rolled back together with the state, that an in-batch APPROVE is unrolled (nonce increment and max_cost collection included), and that a transaction left with payer unset is invalid per the existing end-of-frames check.

No behavior changes for transactions that approve payment outside a batch, and public-mempool handling is unaffected (the validation prefix already may not contain ATOMIC_BATCH_FLAG frames).