EIP-8369: transport committed Frame omission claims across the CL↔EL boundary

## Problem

EIP-8369 Profile 2 evaluates an omitted EIP-8141 Frame transaction at a builder-claimed transaction index. The EIP explicitly leaves the binding mechanism to a Standards Track extension and requires that claims be encoded, carried, committed, passed to the execution layer, retained/pruned across branches, and default safely when absent or malformed.

The current Bogota Engine API transports the inclusion-list transactions into `engine_newPayloadV6` and returns `PayloadStatusV2.inclusionListSatisfied`, but it has no input for the claimed evaluation indices needed to reproduce a Profile-2 omission decision.

That leaves a deterministic-consensus gap once Frame transactions become FOCIL-enforceable: two ELs can receive the same payload + IL but cannot reproduce the same Profile-2 verdict unless they receive the same committed claim set.

## Proposed boundary

Define one canonical claim object at the Engine boundary:

```text
FrameInclusionClaimV1
transactionHash: DATA, 32 Bytes
transactionIndex: QUANTITY, 64 Bits
```

and a canonical ordered collection:

```text
frameInclusionClaims: Array of FrameInclusionClaimV1
```

Normative properties:

1. `transactionHash` identifies the exact EIP-2718 envelope represented by an IL occurrence. The enforcing consensus spec should define the exact digest/lookup rule; the Engine API should carry the resulting identifier verbatim.
2. Claims are sorted in strictly ascending `transactionHash` order; duplicate identifiers are invalid at the transport/structure layer.
3. `transactionIndex` is interpreted in `[0, len(executionPayload.transactions)]`, with `0` before the first payload transaction.
4. A missing claim defaults to `len(executionPayload.transactions)`.
5. A structurally valid but out-of-range index also defaults to `len(executionPayload.transactions)` rather than becoming an omission excuse.
6. Claims that do not correspond to a transaction in the retained IL set are ignored for omission evaluation.
7. The collection must have consensus-defined count/byte bounds; the Engine API should reject structurally over-bound inputs before replay.

## Engine API integration

For the first Engine API version that enables Profile-2 enforcement:

- extend the payload-validation call with `frameInclusionClaims` alongside `inclusionListTransactions`;
- the EL computes `inclusionListSatisfied` from the payload, retained/provided IL transactions, and the supplied claim set;
- if payload production is performed by the EL, the corresponding `getPayload` result must expose the claims produced for omitted Profile-2 transactions so the CL can commit/carry them using the consensus-layer mechanism;
- retained IL/claim data must remain branch-associated for the same lifecycle in which `inclusionListSatisfied` may need to be recomputed.

This issue intentionally does **not** choose the consensus-layer commitment location. That belongs in the EIP-7805/EIP-8141 Standards Track extension. The Engine API requirement is narrower: once the CL has authenticated a claim set, every EL must receive the same set and derive the same observable verdict.

## Conformance invariant

For identical `(payload, inclusionListTransactions, frameInclusionClaims, fork context)`:

```text
EL_A.inclusionListSatisfied == EL_B.inclusionListSatisfied
```

The conformance corpus should include missing claims, out-of-range claims, duplicate claims, unknown transaction identifiers, index 0, end-of-payload, and a Frame transaction whose validity changes at an intermediate index.

## Why separate this scope

This is transport/commitment plumbing, not the Profile-2 replay algorithm itself. Keeping it separate allows consensus to approve or reject the claim handoff independently from the AA-VOPS state surface and replay bounds.

Related: EIP-7805, EIP-8141, EIP-8369, EIP-7928, EIP-7732.

Start by reading the current Bogota Engine API payload-validation and getPayload definitions, then compare the related EIP-7805, EIP-8141, EIP-8369, EIP-7928, and EIP-7732 requirements. Done means the Engine boundary and conformance expectations for frameInclusionClaims are specified consistently, including malformed, missing, unknown, duplicate, and out-of-range claims.

Written by the indexing model from the issue text.