Fix vectorset context reuse after checkpoint/recovery metadata skew

[tiagonapoli]

Problem

Element records in a vector set are keyed by context namespace only (no generation/epoch tag), and context ids are recycled. In the create-on-read path the index-config record — which pins the chosen context id — is written to the store before UpdateContextMetadata flushes that context's in-use bit.

If a checkpoint is taken (or a crash occurs) in that window, the index-config becomes durable while the persisted ContextMetadata still reports the context free. On recovery, NextVectorSetContext re-hands-out that context to an unrelated vector set, and the two sets collide on the same namespace. This is the root cause of the flaky RecreateIndexesOnRestoreAsync failure (Expected: 2 But was: 4).

Fix

In ResumePostRecovery, for every recovered index-config whose context metadata reports it free, reconcile it back to in-use — using the hash slot recovered from the index record's key. A recovered context can never be re-handed-out, closing the skew window.

Test

Adds CreateMetadataSkewRecyclesLiveContextOnRestoreAsync — a deterministic repro driven purely by real ops (VADD / VSIM / Save / recover) plus a single timing gate (VectorSet_Interrupt_Before_Create_Metadata_Persist) that throws in the skew window. No synthetic state mutation. The gate throws (rather than parks) so the create unwinds and releases its lock/epoch, allowing a foreground checkpoint without deadlock.

• Without the fix: fails deterministically (Expected 0 But was 1 — a second vector set surfaces through the recovered context's namespace).
• With the fix: passes.

Validation

• Repro fails without the fix, passes with it (both TestFixture variants).
• Full Garnet.test.vectorset suite: 167 passed, 2 skipped, 0 failed.