Fix test_type_promotion_int64_and_float64_up_to_float64 (#2557)

#### Reference Issues/PRs
<!--Example: Fixes #1234. See also #3456.-->
https://man312219.monday.com/boards/7852509418/pulses/9672110281
#### What does this implement or fix?
There are disparity of overflowing handling in Linux vs Mac (should be
AMD64 vs ARM64, but I don't have another ARM/mac on Intel device to
verify), e.g.
C++:
`(int32_t)(double(std::numeric_limits<int32_t>::max()) + 1)`
Linux:
-2147483648
Mac:
2147483647
numpy:
Linux:
```
In [3]: np.int64(np.float64(np.iinfo(np.int64).max))
<ipython-input-3-f88214db3f1b>:1: RuntimeWarning: invalid value encountered in cast
  np.int64(np.float64(np.iinfo(np.int64).max))
Out[3]: np.int64(-9223372036854775808)
```
macOS:
```
In [5]: np.int64(np.float64(np.iinfo(np.int64).max))
<ipython-input-5-f88214db3f1b>:1: RuntimeWarning: invalid value encountered in cast
  np.int64(np.float64(np.iinfo(np.int64).max))
Out[5]: np.int64(9223372036854775807)
```

So the test is modified to handle such disparity
#### Any other comments?

#### Checklist

<details>
  <summary>
   Checklist for code changes...
  </summary>
 
- [ ] Have you updated the relevant docstrings, documentation and
copyright notice?
- [ ] Is this contribution tested against [all ArcticDB's
features](../docs/mkdocs/docs/technical/contributing.md)?
- [ ] Do all exceptions introduced raise appropriate [error
messages](https://docs.arcticdb.io/error_messages/)?
 - [ ] Are API changes highlighted in the PR description?
- [ ] Is the PR labelled as enhancement or bug so it appears in
autogenerated release notes?
</details>

<!--
Thanks for contributing a Pull Request to ArcticDB! Please ensure you
have taken a look at:
- ArcticDB's Code of Conduct:
https://github.com/man-group/ArcticDB/blob/master/CODE_OF_CONDUCT.md
- ArcticDB's Contribution Licensing:
https://github.com/man-group/ArcticDB/blob/master/docs/mkdocs/docs/technical/contributing.md#contribution-licensing
-->

Author: phoebusm

python/tests/unit/arcticdb/version_store/test_column_type_changes.py

@@ -220,7 +220,6 @@ def test_type_promotion_int32_and_float32_up_to_float64(lmdb_version_store_dynam
     assert data.dtypes["a"] == np.float64
     assert expected_result.dtypes["a"] == np.float64
 
-@pytest.mark.xfail(MACOS, reason="bug??? https://github.com/man-group/ArcticDB/actions/runs/16517098026/job/46710177373?pr=2506")
 def test_type_promotion_int64_and_float64_up_to_float64(lmdb_version_store_dynamic_schema):
     """We unavoidably lose precision in this case, this test just shows what happens when we do."""
     # Given
@@ -241,14 +240,13 @@ def test_type_promotion_int64_and_float64_up_to_float64(lmdb_version_store_dynam
     # When
     data = lib.read("test").data.astype(original_type)
 
-    # Then
-    if MACOS_WHEEL_BUILD:
-        # This test gives other results on MacOS, but it's not a problem for us as the assertions below are meant
-        # for illustrating the issue, not for testing the behaviour strictly.
-        return
-
     assert data.iloc[0, 0] == np.iinfo(original_type).min  # out by one compared to original
-    assert data.iloc[1, 0] == np.iinfo(original_type).min  # overflowed
+    if MACOS: # Should be related to the disparity of overflow handling in ARM64 vs x86_64 rather than OS
+        # e.g. (int32_t)(double(std::numeric_limits<int32_t>::max()) + 1)
+        # -2147483648 on linux, 2147483647 on macOS
+        assert data.iloc[1, 0] == np.iinfo(original_type).max
+    else:
+        assert data.iloc[1, 0] == np.iinfo(original_type).min  # overflowed
     assert data.iloc[2, 0] == 2 ** 53 - 1  # fine, this fits in float64 which has an 11 bit exponent
     assert data.iloc[3, 0] == 2 ** 53  # also fine
     assert data.iloc[4, 0] == 2 ** 53  # off by one, should be 2 ** 53 + 1 but we lost precision