Multiplayer vector deserialization trusts unbounded advertised sizes

Summary

src/multiplayer/basic.h trusts vector sizes read from a multiplayer DataBuffer and calls std::vector::resize() before applying any upper bound.

Affected paths on current master:

• generic sp::io::operator>>(DataBuffer&, std::vector<T>&) around line 10 (uint32_t size);
• BASIC_REPLICATION_VECTOR receive path around line 86 (size_t size).

A malformed or hostile session peer can advertise a very large size with a small packet. The receiver attempts the allocation before reading the vector elements or sparse updates, which can cause memory exhaustion, std::bad_alloc, or process termination. The later index check in BASIC_REPLICATION_VECTOR protects element access but runs only after the resize.

Scope

This is a denial-of-service risk, not a demonstrated code-execution issue. The realistic boundary is a peer able to send multiplayer traffic to a game session; I am not assuming the service is publicly exposed.

The same code is currently present in downstream fork VaroTv7/espaciokooplagunak and is tracked there as VaroTv7/espaciokooplagunak#271.

Suggested direction

Reject advertised vector sizes above an explicit protocol limit before resizing, for both paths. The incremental vectors currently using BASIC_REPLICATION_VECTOR are beam mounts, shield entries and missile-tube mounts, so a conservative protocol maximum can still be far above legitimate ship data.

It would also be useful to add a focused deserialization regression that feeds an oversized declared count and verifies that no resize/allocation is attempted. I have intentionally not included a network exploit payload.

Start in src/multiplayer/basic.h, examining the generic DataBuffer vector deserializer around line 10 and the BASIC_REPLICATION_VECTOR receive path around line 86. Trace the existing multiplayer tests or deserialization test setup, then add coverage for an oversized declared count. Done means both paths reject the count before resizing or allocation and legitimate vector data still deserializes correctly.