eth_createAccessList: clarify gas-fee affordability when fee fields are omitted

## Summary

The `eth_createAccessList` specification accepts a generic transaction object, and both the specification example and an existing conformance fixture omit `gas` and all fee fields. However, the specification does not define whether a client may reject such a request because the sender cannot afford fee values selected by the client as simulation defaults.

This matters for an unfunded sender with zero transaction value: four major execution clients currently generate the access list successfully, while Geth rejects the request after populating default EIP-1559 fee values.

## Reproduction scope

The narrow case discussed here is:

- `from` is explicitly supplied and has zero balance;
- `to` has no code;
- `value` is zero or omitted;
- `gas` is omitted;
- `gasPrice`, `maxFeePerGas`, and `maxPriorityFeePerGas` are all omitted;
- the request targets a state where access-list transactions are active.

Request:

```json
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_createAccessList",
"params": [{
"from": "0xaa00000000000000000000000000000000000000",
"to": "0xbb00000000000000000000000000000000000000"
}, "latest"]
}
```

Preconditions:

```text
eth_getBalance(0xaa...) = 0x0
eth_getCode(0xbb...) = 0x
```

## Current client behavior

Retested on 2026-07-22:

| Client | Version | Result |
| --- | --- | --- |
| Reth | v2.4.1 (`8eb2101`) | success |
| Nethermind | 1.39.2 (`65689105`) | success |
| Besu | 26.7.0 | success |
| Erigon | v3.5.2 (`8a829d21`) | success |
| Geth | master `6e49f8e6b340` | insufficient-funds error |

Reth, Nethermind, Besu, and Erigon all returned:

```json
{
"accessList": [],
"gasUsed": "0x5208"
}
```

The successful clients were tested on development chains with equivalent relevant state. Reth, Besu, and Erigon used their built-in dev chains; Nethermind used a minimal London-active genesis. This was not yet run as a single shared Hive fixture.

Geth currently fails with:

```text
failed to apply transaction: ... err: insufficient funds for gas * price + value:
address 0xaa00000000000000000000000000000000000000
have 0 want 17500000000000000
```

The original Geth issue and the updated reproduction/client matrix are here:

- https://github.com/ethereum/go-ethereum/issues/25319
- https://github.com/ethereum/go-ethereum/issues/25319#issuecomment-5036888995

## Existing specification coverage

The current method definition says only that `eth_createAccessList` “Generates an access list for a transaction” and does not define fee-default or affordability behavior:

https://github.com/ethereum/execution-apis/blob/main/src/eth/execute.yaml

The existing `create-al-value-transfer.io` fixture already omits `gas` and all fee fields and expects success, but it uses a funded sender:

https://github.com/ethereum/execution-apis/blob/main/tests/eth_createAccessList/create-al-value-transfer.io

The missing edge case is an unfunded sender with zero value.

## Proposed clarification

One possible normative clarification is:

> When all gas fee fields are omitted, the client may select implementation-defined fee values for simulation. The request MUST NOT fail solely because the sender cannot afford gas fees implied by those client-selected defaults. This does not waive balance requirements for a non-zero transaction value.

This wording would not require clients to use a zero gas price or standardize their fee oracle. It would only prevent client-selected defaults from introducing an affordability failure that was not present in the request.

Normal RPC gas caps, execution timeouts, and other resource limits would continue to apply.

## Proposed conformance case

A fixture using an address absent from the test genesis could expect:

```text
>> {"jsonrpc":"2.0","id":1,"method":"eth_createAccessList","params":[{"from":"0xaa00000000000000000000000000000000000000","to":"0xbb00000000000000000000000000000000000000"},"latest"]}
<< {"jsonrpc":"2.0","id":1,"result":{"accessList":[],"gasUsed":"0x5208"}}
```

## Out of scope

This proposal intentionally does not define:

- behavior when `value` is non-zero and the sender cannot fund the transfer;
- behavior when fee fields are explicitly supplied;
- a universal default value for `GASPRICE` or other fee-sensitive execution context;
- general `eth_estimateGas` affordability semantics.

The immediate question is whether clients agree on the narrow behavior above and whether it should be made explicit in the specification and rpc-compat suite.

Start with src/eth/execute.yaml and the existing tests/eth_createAccessList/create-al-value-transfer.io fixture, then compare their stated behavior with the unfunded-sender reproduction and client results in this issue. Done means the project reaches agreement on the narrow fee-affordability rule and records the clarification and corresponding conformance coverage.

Written by the indexing model from the issue text.