Bug: Serial Euclidean distance returns zero after floating-point overflow

Reproduced with `Float64` and `BFloat16` on NumKong v7.8.2, Linux x86_64, GCC 13.3.

`cc -O2 -ffp-contract=off -Iinclude repro.c -lm -o repro`

```c++
#include
#include

int main(void)
{
double a[4] = {1e154, 1e154, 1e154, 1e154};
double b[4] = {0, 0, 0, 0};
double squared, distance;
nk_sqeuclidean_f64_serial(a, b, 4, &squared);
nk_euclidean_f64_serial(a, b, 4, &distance);
printf("squared distance: %g\n", squared);
printf("distance: %g\n", distance);
return 0;
}
```

This returns zero distance between vectors that are approximately `2e154` apart, effectively reporting a perfect match. If computing the finite result is impractical because intermediate values overflow, `+inf` would be preferable to zero as it preserves the fact that this is a very distant vector. It matters for ClickHouse because we select the nearest neighbours using `ORDER BY distance LIMIT k`.

The same failure occurs for `BFloat16`: `[1e19,1e19,1e19,1e19]` versus zero returns zero instead of approximately `2e19`.

### Are you open to being tagged as a contributor?

- [x] I am open to being mentioned in the project `.git` history as a contributor

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct