text: Title: What scalar type is expected for DataFrame.divisions?
  Body: **Describe the issue**:
  
  On dask main, `DataFrame.divisions` is a `tuple[np.ndarrray]` where each element is a scalar ndarray:
  
  **Minimal Complete Verifiable Example**:
  
  ```python
  In [1]: import dask.dataframe as dd, pandas as pd
  In [2]: index = [1, 5, 10, 11, 12, 100, 200, 300]
     ...: df = pd.DataFrame({"a": range(8), "index": index}).set_index("index")
     ...: ddf = dd.from_pandas(df, npartitions=3)
     ...: ddf.divisions
     ...: 
  Out[2]: (np.int64(1), np.int64(11), np.int64(200), np.int64(300))
  ```
  
  In this case, that's coming from `sorted_division_locations`, which eventually does a bunch of `Index.__getitem__` calls, which returns scalar ndarrays:
  
  ```
  (Pdb) pp seq
  Index([1, 5, 10, 11, 12, 100, 200, 300], dtype='int64', name='index')
  (Pdb) pp seq[0]
  np.int64(1)
  ```
  
  **Anything else we need to know?**:
  
  Would we prefer that divisions be a tuple of plain Python scalars? IIRC, that's what it was previously, and would I think fit better with how it's used (comparisons).
  
  xref https://github.com/rapidsai/dask-upstream-testing/issues/9, where `pd.isna` check downstream of `.divisions` is causing issues for dask-cudf. But I suspect that solving this when we build divisions might be preferable. I'm able to solve this pretty easily in `sorted_division_locations`, but I think there are other spots where divisions is created (like indexing) and wanted to check whether anyone had a preference before going any further.
  
  **Environment**:
  
  - Dask version: `2025.2.0+11.gf67825a60`
  - Python version:
  - Operating System:
  - Install method (conda, pip, source):
  