eth, blobpool: reconcile cell fetching after custody updates

[reddaisyy]

Description

engine_forkchoiceUpdatedV4 forwards every non-nil custodyColumns
update to BlobFetcher.UpdateCustody:

if custodyColumns != nil {
    api.eth.BlobFetcher().UpdateCustody(*custodyColumns)
}

However, the fetcher loop currently only replaces the bitmap:

case cells := <-f.custodyCh:
    f.custody = cells

This makes new announcements observe the new custody set, but it does not reconcile queued, in-flight, or already pooled partial blob transactions whose state was created under the previous custody set.

EIP-8070 is currently in Review. Its Engine API specification requires:

• all subsequent sampling requests to adopt the new custody set;
• pending type-3 transactions to be sampled for delta columns when the custody set expands;
• an identical custody value, or null, to be treated as a blobpool-state no-op.

The specification permits, but does not require, already queued sampling requests to be patched.

Reconcile sparse blob cell fetching when the custody set changes.

Previously, BlobFetcher.UpdateCustody only replaced the current custody bitmap. Existing partial fetches and transactions already stored in the blobpool were not updated to fetch newly required columns. Completion also required exact equality between fetched and custody indices, so a custody contraction could leave a fetch incomplete when extra cells had already been received.

This change:

• treats identical custody updates as no-ops;
• requests only newly required columns after custody expansion;
• uses custody coverage instead of exact equality for completion;
• reconciles transactions in waitlist, announcement and active-fetch states;
• retains peer availability for later custody expansion;
• supplements partial transactions already stored in the blobpool;
• verifies and atomically persists merged cells;
• falls back to the blobpool when cached cells do not cover the requested mask.

Tests

Added regression coverage for:

• custody expansion and delta-column requests;
• custody contraction with extra fetched cells;
• identical custody updates;
• updates during availability waiting;
• supplementing an existing pooled transaction;
• reactivating a pooled transaction after later expansion;
• verified multi-blob cell merging and persistence.