`SerializationReplicated::deserializeBinaryBulkWithMultipleStreams` read a
client-supplied replicated-index buffer from the native TCP protocol and
validated only the index row count, not the index values. Every
`ColumnReplicated` accessor then dereferences `nested_column[index]` without
a bound, so a crafted `REPLICATED`-serialized column whose indexes point past
the nested ("elements") column produces an out-of-bounds read when the column
is materialized.

Validate every deserialized index against the number of nested elements
(throwing `INCORRECT_DATA`) before attaching the indexes, mirroring the
per-discriminator check already done in `SerializationVariant`.

Reachable only over the native TCP protocol (negotiated revision >=
`DBMS_MIN_REVISION_WITH_REPLICATED_SERIALIZATION`); the format layer builds
`NativeReader` with `server_revision = 0`, so `REPLICATED` is never read there.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

`checkDeserializedIndexes` only proved that replicated indexes are less
than the advertised `num_elements`; it never proved that
`nested->deserializeBinaryBulkWithMultipleStreams` actually produced
`num_elements` rows. Primitive bulk readers such as
`SerializationNumber::deserializeBinaryBulk` short-read on EOF instead of
throwing, and `NativeReader::readData` only checks the top-level
`column->size()`, which for `ColumnReplicated` is the index count, not the
nested column size. So a client could send in-range indexes, advertise
`num_elements = N`, truncate the elements payload, and still hand an
out-of-bounds-capable `ColumnReplicated` to the executor.

Verify `column_replicated.getNestedColumn()->size() == num_elements` after
the nested deserialization and throw `INCORRECT_DATA` on mismatch,
mirroring the post-read consistency checks in `SerializationArray` and
`SerializationVariant`. Extend the regression test with a second scenario
covering in-range indexes plus a truncated elements stream.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>