`bitwise*` operators won't check arguments type when short circuited (Found by SQLancer-NoREC)

### Describe the bug

All bitwise operators https://datafusion.apache.org/user-guide/sql/operators.html#op-bit-and don't allow two arguments both to be `Double` type, but if the bitwise expression is short-circuited, then type check won't be performed.
This bug can be reproduced with any bitwise operator

```
> select 3.1<<3.2;
Internal error: Data type Float64 not supported for binary operation 'bitwise_shift_left' on dyn arrays.
This was likely caused by a bug in DataFusion's code and we would welcome that you file an bug report in our issue tracker
> select (false and (3.1<<3.2) > 0);
+------------------------------------------------------------+
| Boolean(false) AND Float64(3.1) << Float64(3.2) > Int64(0) |
+------------------------------------------------------------+
| false |
+------------------------------------------------------------+
1 row(s) fetched.
Elapsed 0.003 seconds.
```
It's better to return a planning error, because strictly (3.1<<3.2) should be an invalid expression like the following one, and can't be short-circuited
```
> select (false and (1 + 'foo'));
Error during planning: Cannot coerce arithmetic expression Int64 + Utf8 to valid types
```

### To Reproduce

_No response_

### Expected behavior

_No response_

### Additional context

Found by SQLancer https://github.com/apache/datafusion/issues/11030

Start by running the two SQL queries in the issue and compare their behavior with the invalid arithmetic example. Trace DataFusion's planning and type-checking path for bitwise operators inside short-circuited boolean expressions. Done means every invalid bitwise operand combination, including the short-circuited case, returns a planning error rather than executing.

Written by the indexing model from the issue text.