fix(milvus): make metric type configurable to prevent mismatch errors

[octo-patch]

Fixes #6033

Problem

The Milvus node hardcoded MetricType.L2 when creating a new index in MilvusUpsert.addVectors(). Users with collections configured to use COSINE or IP metric types encountered metric type mismatch errors during vector insertion, because the index was always created with L2 regardless of the collection's actual metric type.

Solution

• Added a Metric Type dropdown input parameter to the Milvus node (under Additional Parameters) with options: L2 (default, backward-compatible), COSINE, and IP
• The selected metric type is passed via indexCreateParams in MilvusLibArgs during upsert
• MilvusUpsert.addVectors() now uses this.indexCreateParams?.metric_type ?? MetricType.L2 instead of the hardcoded MetricType.L2, ensuring the index is created with the correct metric type
• Bumped node version from 2.1 to 2.2

Testing

• Users can now select the appropriate metric type matching their Milvus collection configuration
• Defaults to L2 for full backward compatibility with existing flows
• The similarity search already read vectorStore.indexCreateParams.metric_type correctly — this fix aligns upsert to do the same

[gemini-code-assist]

Code Review

This pull request updates the Milvus vector store component to version 2.2 and introduces a configurable 'Metric Type' input for similarity searches, supporting L2, COSINE, and IP metrics. While the metric type is correctly implemented for upsert operations, it is currently missing from the 'init' method. This omission will cause retrieval and search operations to ignore the user-selected metric, potentially leading to incorrect results or runtime errors when accessing index parameters.

[gemini-code-assist]

The new milvusMetricType input is correctly utilized in the upsert method, but it is missing from the init method (lines 266-347). This is a significant oversight because when the node is used for retrieval (the retriever output) or to connect to an existing collection, it will ignore the user-selected metric type.

This leads to two issues:

1. Potential Crash: similaritySearchVectorWithScore (line 387) and the score normalization logic (line 420) both access vectorStore.indexCreateParams.metric_type. If indexCreateParams is not provided in init, this may throw an error or result in incorrect search behavior.
2. Metric Mismatch: Search operations will use the default metric type instead of the one configured by the user, which is the exact problem this PR aims to solve for upserts.

The init method needs to extract milvusMetricType and include it in milVusArgs.indexCreateParams similarly to the upsert implementation.

References

1. When a feature requires a specific configuration, it is preferable to throw an error if the configuration is missing rather than silently falling back to a different implementation.