`log(base, val)` loses precision when `value` is `Float32`

### Describe the bug

```
> SELECT log(arrow_cast(16777217,'Float64'), arrow_cast(2.0,'Float32'));
+-----------------------------------------------------------------------------------------+
| log(arrow_cast(Int64(16777217),Utf8("Float64")),arrow_cast(Float64(2),Utf8("Float32"))) |
+-----------------------------------------------------------------------------------------+
| 0.041666668 |
+-----------------------------------------------------------------------------------------+
1 row(s) fetched.
Elapsed 0.006 seconds.

> select log(arrow_cast(16777217,'Float64'), arrow_cast(2.0,'Float64'));
+-----------------------------------------------------------------------------------------+
| log(arrow_cast(Int64(16777217),Utf8("Float64")),arrow_cast(Float64(2),Utf8("Float64"))) |
+-----------------------------------------------------------------------------------------+
| 0.041666666517376175 |
+-----------------------------------------------------------------------------------------+
1 row(s) fetched.
Elapsed 0.006 seconds.
```

When called with `Float64` (or integer) base and `Float32` value, we narrow the `base` to `Float32`; we should instead widen `value` to `Float64` and return a Float64.

### To Reproduce

_No response_

### Expected behavior

_No response_

### Additional context

_No response_

Reproduce the two SELECT log queries shown in the issue and compare their result types and precision. Start at the implementation and type-coercion path for the SQL log function; the fix is done when a Float64 base with a Float32 value returns a precise Float64 result, with regression coverage for this case.

Written by the indexing model from the issue text.