feat: Add EIP-8130 spec

[lukasrosario]

Description

Specifies how the OP Stack integrates EIP-8130, which
introduces account abstraction through onchain account configuration and a new EIP-2718 transaction
type (0x79).

Adds specs/experimental/eip-8130.md covering the parts that are OP-specific: activation, the chain
parameters the EIP leaves to the chain, span-batch encoding so 0x79 transactions survive
derivation, the receipt surface, and the enshrined system addresses.

It deliberately does not restate the account model, the authenticator set, the actor scope rules,
the intrinsic gas schedule, or the execution semantics. Those are normative in the EIP and apply
unchanged. The document says so explicitly and states that where it is silent, the EIP governs.
EIP-8130 is still a Draft, so this keeps the spec from drifting as the EIP moves and keeps the review
surface here to what the OP Stack actually adds.

EIP-8130 is not yet assigned to a network upgrade, so the spec names none and lives under
experimental/ alongside the other unscheduled specs.

Tests

No automated tests. This is a specification-only change. just lint-check passes: markdownlint,
doctoc, cspell, and the filename check are all clean, and the five external EIP links return 200.

The wire format the document specifies is not novel and is not being introduced here. It is
specified as already implemented and tested in Base's stack, in both Rust and Go, so there are two
interoperating implementations behind it rather than a paper design. Client-side test coverage lands
with the implementation PRs.

Additional context

The consensus-critical parts, in rough order of risk, are where review attention is most useful:

• Span-batch encoding. The txs payload gains one trailing column, eip8130_auth_data. Each
  transaction's sender_auth/payer_auth blob is split: the low-entropy 20-byte authenticator
  address stays in the tx_datas body and the high-entropy proof bytes move to the new column. The
  column trails every other column so a decoder can identify 0x79 transactions from the leading
  type byte of each tx_datas entry before reading it. That avoids an additional bitlist and means
  a batch with no 0x79 transactions encodes byte-identically to one produced before activation.
• Decode rules, particularly rule 4: a configured actor must carry exactly a 20-byte
  authenticator and an EOA or self-pay actor must carry none. Without that binding, a batch can
  declare a configured actor while carrying an empty authenticator and reconstruction silently
  produces a corrupt authorization blob instead of failing.
• Chain parameters. REPLAY_BUFFER_CAPACITY and NONCE_FREE_EXPIRY_WINDOW are consensus, not
  node policy — the EIP is explicit that a per-node buffer capacity would split consensus. The spec
  requires they be sized together so a ring entry always expires before its slot is reused, and
  separates them from limits a node may legitimately apply locally.
• Receipt layering. The consensus receipt is a plain EIP-1559-shaped receipt; payer and
  phaseStatuses are RPC-only and excluded from the RLP encoding, and therefore from the receipts
  root. The spec also states that a failed status does not imply a no-op, since committed earlier
  phases, applied account changes, auto-delegation, nonce consumption, and gas payment all persist
  through a later phase revert.
• Nullable address encoding. Absent sender/payer are zero-length byte strings and a
  present-but-zero address is a distinct value. This separates the EOA path from the configured-actor
  path and self-pay from sponsored pay, so it has to survive every codec.

Open items I'd like input on:

1. Should the trailing column be explicitly fork-gated? The byte-compatibility argument says it
   needn't be, since a batch with no 0x79 transactions is unchanged. Flagging in case reviewers
   want an explicit gate anyway.
2. payer field ordering. It precedes account_changes in the span-batch body but follows
   metadata in the EIP-2718 encoding. Specified as implemented, but the asymmetry looks accidental
   rather than designed, and normalizing it is far cheaper now than after clients ship.
3. Chain parameter values. The spec pins the requirement and the sizing relationship but not the
   numbers, which need choosing per chain.