Ambiguous batch format

According to the [Channel Format](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#channel-format) section, `rlp_batches` is the concatenation of the RLP-encoded batches. This is somewhat misleading, as `rlp_batches` is not
```
batch1_version ++ rlp_encode([..]) ++ ... ++ batchn_version ++ rlp_encode([..])
```
(similar to a list of EIP-2718 transactions), but instead
```
rlp_encode(batch1_version ++ rlp_encode([..])) ++ ... ++ rlp_encode(batchn_version ++ rlp_encode([..]))
```
It should be made clear in the spec that `rlp_batches` is the concatenation of the RLP-encoded strings `batch_data`, where `batch_data = batch_version ++ content` as described in the section [Batch Format](https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-format).

And perhaps more importantly, it should be made clear what is supposed to happen during decoding, if the "byte envelope" is larger than `batch_version ++ content`. For example, if for `rlp_encode(batch1_version ++ rlp_encode([..]))` resulting in
```
b85000f84da0dbf6a80fef073de06add9b0d14026d6e5a86c85f6d102c36d3d8e9cf89c2afd3840109d8fea0438335a20d98863a4c0c97999eb2481921ccd28553eac6f913af7c12aec0410884647f5ea9c0
```
the following (adding a bunch of useless zeros) would also be valid:
```
b85800f84da0dbf6a80fef073de06add9b0d14026d6e5a86c85f6d102c36d3d8e9cf89c2afd3840109d8fea0438335a20d98863a4c0c97999eb2481921ccd28553eac6f913af7c12aec0410884647f5ea9c00000000000000000
```

If different implementations handle this decoding differently, it could lead to a chain fork.

Read the Channel Format and Batch Format sections in specs/protocol/derivation.md, along with the linked batch_data description. Confirm the intended RLP envelope and decoding behavior when extra bytes remain, then update the specification so the encoding and rejection or acceptance rules are explicit.

Written by the indexing model from the issue text.