engineapi: complete Amsterdam REST-SSZ blob and custody support

## Problem

The REST-SSZ Engine API introduced by #21729 does not yet implement two Amsterdam requirements from [execution-apis#793](https://github.com/ethereum/execution-apis/pull/793):

- `POST /engine/v1/blobs/v4` is not implemented or advertised. The current draft requires an Amsterdam EL to serve v4, which adds cell-range selection.
- `POST /engine/v1/forkchoice` decodes and validates `custody_columns` but does not apply it. The current draft requires an accepted custody set to remain active until another forkchoice update replaces it; omitting the field must leave the set unchanged.

Consequently, Erigon can advertise Amsterdam among its supported fork schemas without providing the complete Amsterdam behavior.

## Required work

- Add the `/blobs/v4` request and response SSZ types and connect them to a cell-range backend.
- Advertise blob revision v4 only when the endpoint is available.
- Apply `custody_columns` in external-CL mode and preserve the set until it is replaced.
- Keep custody processing independent from forkchoice payload status, as required by the draft.
- Cover v4 selection, partial availability, `204 No Content`, capability advertisement, custody replacement, omitted custody, persistence, and custody-error behavior in tests.

## Specification

- [REST transport and endpoint semantics](https://github.com/ethereum/execution-apis/blob/d39e9a2710bf5f75eddee44fe8c2a6844bea23f0/src/engine/refactor.md)
- [SSZ container catalogue](https://github.com/ethereum/execution-apis/blob/d39e9a2710bf5f75eddee44fe8c2a6844bea23f0/src/engine/refactor-ssz.md)

Follow-up to #21729.