dask.array with query planning misses materialization dunder methods

dask 2025.4.1

`dask.array._array_expr.Array` lacks `__array__`, `__bool__`, `__int__`, `__float__`, `__complex__`, and `__index__` methods.
I am unsure if this is a deliberate change (_it would make sense if it were_, but I cannot find documentation); regardless the user-facing error is obscure. In the case of `np.asarray`, the function doesn't crash but instead returns a numpy array of dask arrays.

```python
>>> import dask
>>> dask.__version__
'2025.4.1'
>>> dask.config.set({"array.query-planning": True})
>>> import dask.array as da
>>> import numpy as np
>>> import operator
>>> a = da.asarray(1)
>>> int(a)
TypeError: int() argument must be a string, a bytes-like object or a real number, not 'Array'
>>> float(a)
TypeError: float() argument must be a string or a real number, not 'Array'
>>> operator.index(a)
TypeError: 'Array' object cannot be interpreted as an integer
>>> bool(a.any())
TypeError: len() of unsized object
>>> np.asarray(a)
array(,
dtype=object)
```

# Expected behaviour
Either
- these functions continue auto-materializing the graph like they do without query planning, with all the pros and the cons involved, or
- they raise a very clear error message that they are no longer meant to work.

I think that the former is a much healthier option. Disabling auto-materialization would be a BIG change (although I would 100% agree with it), so it should be definitely decoupled from the transition to query planning, with a substantial deprecation cycle too.

CC @fjetter

Start with dask.array._array_expr.Array and reproduce the reported int(), float(), operator.index(), bool(), and np.asarray() cases with array.query-planning enabled and disabled. Compare the existing behavior, then determine whether these entry points should materialize or raise a clear error; done means the chosen behavior is consistent and the reported obscure errors are addressed.

Written by the indexing model from the issue text.