Specify SSZ framing for GET /eth/v1/debug/beacon/data_column_sidecars/{block_id}

[syjn99]

GET /eth/v1/debug/beacon/data_column_sidecars/{block_id} declares its SSZ response as:

SSZ serialized DataColumnSidecars bytes.

DataColumnSidecars is not an SSZ type, so it might be confusing for encoding the response. Here's a research conducted by Claude:

Client	Framing	Source
Lighthouse	List	beacon_node/http_api/src/lib.rs → data_columns.as_ssz_bytes() on DataColumnSidecarList = Vec<Arc<DataColumnSidecar<E>>> (offset-framed for variable-size T)
Nimbus	List	beacon_chain/rpc/rest_debug_api.nim → handleDataSidecarRequest[..., List[fulu.DataColumnSidecar, NUMBER_OF_COLUMNS]], sszResponse on the List
Lodestar	List	packages/api/src/beacon/routes/debug.ts → sszTypesFor(fork).DataColumnSidecars, i.e. new ListCompositeType(DataColumnSidecar, NUMBER_OF_COLUMNS)
Grandine	List	http_api/src/standard.rs::debug_beacon_data_column_sidecars → DynamicList<Arc<DataColumnSidecar<P>>>, whose SszWrite is shared::write_list
Teku	concatenation	.../v1/debug/GetDataColumnSidecars.java → data.forEach(s -> s.sszSerialize(out))
Prysm	concatenation	beacon-chain/rpc/eth/debug/handlers.go::buildDataColumnSidecarsSSZResponse → loops MarshalSSZ and appends

I can tell Prysm is just concatenating it, so about to fix this.

This PR clarifies and specifies that we are gonna use SSZ List for the response, so the clients can prepend offset bytes before marshalling the items.

[nflaig]

DataColumnSidecars is not an SSZ type, so it might be confusing for encoding the response.

there is the following container defined in the spec

class DataColumnSidecars(List[DataColumnSidecar, compute_max_request_data_column_sidecars()]):
    """
    Data column sidecars returned in a ``DataColumnSidecarsByRange`` or
    ``DataColumnSidecarsByRoot`` response.
    """

where compute_max_request_data_column_sidecars is

def compute_max_request_data_column_sidecars() -> Uint64:
    """
    Return the maximum number of data column sidecars in a single request.
    """
    return Uint64(MAX_REQUEST_BLOCKS_DENEB * NUMBER_OF_COLUMNS)

but this type is used by DataColumnSidecarsByRoot and DataColumnSidecarsByRange, the list limit MAX_REQUEST_BLOCKS_DENEB * NUMBER_OF_COLUMNS is not correct for the api response

we do have the schema defined here

beacon-APIs/types/fulu/data_column_sidecar.yaml

Lines 2 to 7 in 95b9faf

	DataColumnSidecars:
	type: array
	items:
	$ref: '#/Fulu/DataColumnSidecar'
	minItems: 0
	maxItems: 128

but I do think the change in this PR makes sense to avoid potential confusing about the response type

[nflaig]

LGTM, thanks @syjn99