[BUG] Inconsistent behaviour of the floot_divide integer arrays truncates towards 0

☑️ I understand it is strictly prohibited to use AI to write issues.

Describe the bug
The mx.floor_divide is inconsistent , it behaves different based on integer and float dtypes

To Reproduce

Include code snippet

x = mx.array(1, dtype=mx.float32)
y = mx.array(-2, dtype=mx.float32)

z = mx.floor_divide(x, y)

np_x = np.array(1, dtype=np.float32)
np_y = np.array(-2, dtype=np.float32)
np_z = np.floor_divide(np_x, np_y)

print(z)
print(np_z)

outputs:

array(-1, dtype=float32)
-1.0

when changed to int32

x = mx.array(1, dtype=mx.int32)
y = mx.array(-2, dtype=mx.int32)

z = mx.floor_divide(x, y)

np_x = np.array(1, dtype=np.int32)
np_y = np.array(-2, dtype=np.int32)
np_z = np.floor_divide(np_x, np_y)

print(z)
print(np_z)

outputs:

array(0, dtype=int32)
-1

Expected behavior
A clear and concise description of what you expected to happen.

The expected behaviour is that the integer arrays should behave like float arrays instead of truncating towards 0.

Desktop (please complete the following information):

• OS Version: macos tahoe 26.6.1
• Version: 0.32.3.dev20260902+117188cd

Additional context
Discovered while working on data-apis/array-api-compat#451

Start by reproducing the supplied Python examples for mx.floor_divide with float32 and int32 negative operands. Trace the mx.floor_divide entry point into the integer implementation and existing tests, then verify that integer results use floor semantics and match NumPy for the reported cases.