bug(vector_stores/vertex_ai): search score hardcoded for cosine, breaks L2-style indexes

Nobody has claimed this yet.

## Description

Same class of bug as #6546 / #6547 / #7229, in the **Vertex AI Vector Search** store.

`GoogleMatchingEngine` hardcodes cosine-style conversion in three places:

```python
score = max(0.0, 1.0 - raw_distance) # _parse_output / search / get
```

Vertex Matching Engine indexes can be created with **DOT_PRODUCT** / **SQUARED_L2_DISTANCE** (not only cosine). When the underlying index uses L2-style distance, unbounded values make `1 - distance` collapse almost every hit with `d > 1` to `0.0`, destroying ranking and any score thresholds.

`create_col(..., distance=...)` is currently documented as ignored — there is no way for mem0 to know which metric the deployed index uses, so the store always assumes cosine.

## Expected Behavior

- Add an optional `distance_metric` on `GoogleMatchingEngineConfig` (default `cosine`) that the user sets to match their Vertex index.
- Convert distance → similarity in a metric-aware way (same approach as #6547 / #7229):
- cosine: `max(0, 1 - d)`
- euclidean / squared L2: `1 / (1 + d)`
- (dot product: treat carefully; often already similarity-like depending on Vertex config)

## Additional Context

- Sibling of #6546 (S3) and #7229 (Valkey). Happy to open a PR mirroring #6547 once this has the `accepted` label.
- I am not proposing to change the Vertex index itself — only the client-side score mapping and a config knob so it can match the deployed index metric.

Start by locating the GoogleMatchingEngine class, its GoogleMatchingEngineConfig, and the _parse_output, search, and get entry points. Trace how raw_distance becomes score and how create_col distance is documented. Done means an optional distance_metric selects the documented cosine or L2-style mapping without collapsing valid L2 scores, with coverage for the supported metrics.

Written by the indexing model from the issue text.