BUG: validate_where $in/$nin type check is order-dependent for bool/int mixed lists

## What breaks

`validate_where` rejects `{"$in": [True, 1]}` but silently accepts `{"$in": [1, True]}`, even though both represent the same mixed bool/int list. The inconsistency is order-dependent.

```python
from chromadb.api.types import validate_where

validate_where({"field": {"$in": [True, 1]}}) # raises ValueError
validate_where({"field": {"$in": [1, True]}}) # no error — BUG
```

## Root cause

chromadb/api/types.py line 1273 uses `isinstance(x, type(operand[0]))` to enforce homogeneity. Because `bool` is a subclass of `int`, `isinstance(True, int)` is `True` but `isinstance(1, bool)` is `False`. The result flips depending on which element appears first. The same file already demonstrates the correct fix in `_validate_metadata_list_value` (lines 1049–1059), which normalizes types by checking for `bool` before `int`.

Start in chromadb/api/types.py at line 1273 and compare the type check with _validate_metadata_list_value around lines 1049–1059. Verify that validate_where handles both [True, 1] and [1, True] consistently, with completion shown by both examples producing the same validation result.

Written by the indexing model from the issue text.