[BUG] Duplicate external labels in HNSW cause load validation to fail

[BCathcart]

Describe the bug
The validation code asserts that there are only unique external labels in the data_level0_memory_ slots. This is not always the case. I don't see any inherent problems with this state. The one place it can go wrong today is across a save/load. The load code rebuilds the label_lookup_ from the labels in data_level0_memory_. There can be one live slot and any number of tombstoned slots all carrying the same label. The label_lookup_ reconstruction code needs to check that it points to the live slot for that label. Otherwise the HNSW state won't properly reflect the keyspace. Future updates or deletes to the record will error as it will see the label already belonging to a tombstoned node.

To Reproduce
The HNSW modify record code first calls markDelete() on the record to tombstone the existing slot with the label and then calls addPoint() to add the new vector with the exact same label. Theoretically, std::unordered_set<tableint> deleted_elements makes no promises about which slot deleted_elements.begin() points to. In practice though, it's always the last added slot. In the normal case, the same slot will be updated and there will be no duplicate labels. The problem occurs when another document is deleted between markDelete() and addPoint(). It will put another tombstoned slot at the front of deleted_elements and the addPoint() for the modified record will use it, adding the label to a new slot and still keeping the same label in the old slot it just tombstoned.

Expected behavior
Let's not have the load-side validation enforce unique slots. It just needs to properly reconstruct the label_lookup_.

Environment
Search 1.0, 1.1, and 1.2 are all susceptible.

Additional context
Additional problems that make mitigation hard:

• Inability to modify Dev configs outside debug-mode.
• All load validation being is coupled under a single enabled/disabled config, regardless if it's protecting against OOB accesses with security implications or just surfaces a small correctness bug like this one.

[BCathcart]

I don't see any inherent problems with this state.

My test actually does expose a use-after-free problem.

Vector bytes live in a refcounted InternedString. The only owning reference for an indexed vector is the entry in tracked_vectors_. The HNSW slot record stores a raw, non-owning char* to those bytes.

The free happens on modify, at ModifyRecord → TrackVector(id, new_vec):

tracked_vectors_[label] = new_vec;   // overwrites → old InternedStringPtr destructs → refcount-- → frees old_vec

Why only in the race case:

• Normal modify (label stays on its own slot): overwriting tracked_vectors_[label] is correct — the only slot with that label now points at new_vec, and nothing references old_vec. Free is safe.
• Normal delete: UnTrackVector is a no-op, so tracked_vectors_[label] is never erased — the tombstoned slot's vector stays alive. No free.
• Race modify: addPoint(replace_deleted) relocated label onto a different slot, so now two slots carry label. The new live slot (wants new_vec) and the original tombstoned slot (still raw-points at old_vec). The TrackVector overwrite frees old_vec, but the tombstoned slot's raw pointer still references it -> dangling pointer on the tombstoned slot.

This is hit in my test when a save traverses over the slots and tries to save the vector data.

What this means:
I need to fast-track my change to ensure updates always use the same slot. This is already done in the replace-deleted disabled case.