fix(vector): use index metric and efc for post-build HNSW inserts

[adsharma]

Summary

Rows inserted into a table after CREATE_VECTOR_INDEX (via CREATE/MERGE through initInsertState, COPY FROM through finalize, and embedding updates through initUpdateState) had their HNSW neighbours chosen by cosine distance regardless of the index's configured metric.

Root cause

OnDiskHNSWIndex::HNSWInsertState built its HNSWSearchState with a default-constructed HNSWIndexConfig{} (metric = cosine) and default QueryHNSWConfig{} (efs = 200). insertInternal -> searchNNInUpperLayer / insertToLayer -> searchKNNInLayer all score candidates with searchState.metricFunc, so post-build inserts silently used cosine (and default ef) on l2 / l2sq / dotproduct indexes over non-normalized vectors, lowering recall for those rows. The initial build (InMemHNSWIndex), shrink (shrinkForNode uses config.metric), and query path (real index config) were already correct.

Fix

• HNSWInsertState now takes const HNSWIndexConfig& and forwards it to HNSWSearchState instead of HNSWIndexConfig{}.
• New getInsertQueryConfig() helper maps the index's efc onto the insert search's efs, so custom efc is honored for incremental inserts too.
• Both producers (initInsertState, finalize) pass through config.

Testing

• Full vector e2e suite: 87/87 passed (E2E_TEST_FILES_DIRECTORY=extension ... e2e_test --gtest_filter='vector~*').
• New code is clang-format clean.

Related to LadybugDB/ladybug#1023