Fix Vector Set Index key corruption

[kevin-montrose]

As part of moving to Store V2, VADD replication writes were moved into the default namespace. This introduced a subtle corruption issue.

In Store V1, since nothing of value was ever stored in the replication namespace it didn't matter if we were doing an update in place or a copy update. In Store V2 the actual index is stored in the same key, which all works fine until we need to copy the index into the mutable part of the log (ie. do a copy update). Since there's no code for that case in V1, we "copy" an empty value and the next read operation to touch that index gets a corrupted index.

This fixes that by properly copying the index when needed.

[Copilot]

Pull request overview

Fixes a Store V2 regression where Vector Set replication writes (VADD in the default namespace) can trigger a Tsavorite copy-update (CU) that allocates an empty value, corrupting the vector index key on subsequent reads.

Changes:

• Ensure CU sizing accounts for the vector index payload when replaying VADD replication writes.
• Preserve the existing vector index bytes during CU for VADD replication no-op writes (and related CU flows).
• Remove the now-unused DeleteAfterDropArg constant and re-base arg numbering accordingly.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
libs/server/Storage/Functions/MainStore/VarLenInputMethods.cs	Adjusts RMW modified-field sizing for Vector Set operations so CU can reserve enough value space.
libs/server/Storage/Functions/MainStore/RMWMethods.cs	Updates CopyUpdater logic to preserve index bytes during CU for synthetic Vector Set replication writes.
libs/server/Resp/Vector/VectorManager.cs	Updates internal arg constants (removing the deleted Drop-related arg).