[Feature] `PojoDataFileMeta.creationTimeEpochMillis()` may mislead user about the creation time of the file

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar.

### Motivation

`PojoDataFileMeta.creationTimeEpochMillis()` handling logic:

1. Converts the timestamp to LocalDateTime using `toLocalDateTime()` (which ignores timezone information)
2. Then treats this LocalDateTime as if it were in the system default timezone
3. Finally converts it back to epoch milliseconds

This double conversion causes timezone-related errors, especially when the system default timezone is not UTC.
```java
@Override
public long creationTimeEpochMillis() {
return creationTime
.toLocalDateTime()
.atZone(ZoneId.systemDefault())
.toInstant()
.toEpochMilli();
}
```
According to the Javadoc of the `Timestamp` class, the millisecond field already stores the number of milliseconds since the epoch (1970-01-01 00:00:00 UTC).

So `millisecond` in `creationTime` is UTC will be converted to `Asia/Shanghai` timezone millisecond,
which will 8h shift to the left.

This approach can be confusing for user (https://github.com/apache/amoro/issues/4066). I'm wondering if we should simply use the milliseconds directly like this:

```java
@Override
public long creationTimeEpochMillis() {
return creationTime.getTime();
}
```

Please let me know if I'm understanding this correctly or if there are any issues with this approach.

### Solution

_No response_

### Anything else?

_No response_

### Are you willing to submit a PR?

- [x] I'm willing to submit a PR!

Search the repository for `PojoDataFileMeta.creationTimeEpochMillis()` and inspect how `creationTime` is represented and consumed. Verify the behavior with non-UTC system timezones; done means the method reports the stored epoch milliseconds without a timezone-dependent shift.

Written by the indexing model from the issue text.