For some reason, this `reserve()` call was dropped in commit [1] when the
container type was switched from `std::vector<>` to `chunked_vector<>`.

Fix the regression by adding the call to `reserve()` back to the function
before calling `push_back()` in a loop.

[1]: a59cdd8

(cherry picked from commit 75e2239)

….x-183

[v24.3.x] `storage`: call `reserve()` in `storage::range()`

Redpada store `model::record_batch` records as opaque bytes. The bytes
are materialized to individual `model::record` lazily when iterating
over the batch records. During the record materialization record header
vector is parsed. The vector size is stored in a variable length encoded
integer. If the data in the record buffer are invalid the size may be
incorrectly deserialized leading to a very large allocation. Added basic
defensive check that compares the requested vector size with the number
of bytes left in the buffer. It the size is greater then the exception
is thrown as we know that header is never smaller than one byte.

Signed-off-by: Michał Maślanka <michal@redpanda.com>
(cherry picked from commit 7f109db)

….x-914

[v24.3.x] m/record: added very basic defensive check to prevent crashes

(cherry picked from commit 223f63c)

….x-860

[v24.3.x] rpk: Remote bundle upload

We saw an occurance of an oversized allocation in the wild here.

Confusingly enough, the underlying data type of `describe_groups_response_data`
is a `chunked_vector` already, which means we were just moving entries from
an `std::vector` into a `chunked_vector` here anyways.

Use a `chunked_vector<ss::future<described_group>>` for `described`
and `std::move()` assign it to `response.data.groups` to avoid
future potential for an oversized allocation here.

`ssx::when_all_succeed<>()` must be used (as the type is no longer
`std::vector<>`)

(cherry picked from commit 2082d12)

….x-406

[v24.3.x] `kafka`: use `chunked_vector` in `describe_groups_handler::handle`