Inconsistent CAST behavior to DateTime64(3) when reading from Parquet via S3 and directly specified

### Company or project name

_No response_

### Describe the unexpected behaviour

When casting to DateTime64(3), the result differs depending on whether the input value is a hardcoded or comes from a Parquet file read via S3. This leads to inconsistent and confusing results when working with timestamp data stored as integers (e.g., epoch milliseconds).

### How to reproduce

- version : 25.4.1)
- Queries that lead to unexpected result
```
SELECT
1742420262514,
CAST('1742420262514', 'DateTime64(3)'),
timestamputc,
CAST(timestamputc, 'DateTime64(3)')
FROM s3('https://xxx/timestamp.parquet', 'xxx', 'xxx', 'parquet')

Row 1:
──────
1742420262514: 1742420262514 -- 1.74 trillion
CAST('174242⋯Time64(3)'): 2025-03-20 06:37:42.514
timestamputc: 1742420262514 -- 1.74 trillion
CAST(timesta⋯Time64(3)'): 2299-12-31 23:59:59.000
```

[timestamp.parquet.zip](https://github.com/user-attachments/files/19642591/timestamp.parquet.zip)

### Expected behavior

CAST behavior to DateTime64(3) should be consistent regardless of the source. Ideally, numeric values representing epoch milliseconds should be interpreted the same way in all contexts. Therefore, `2025-03-20 06:37:42.514` is the expected result in this case.

### Error message and/or stacktrace

_No response_

### Additional context

_No response_