[Bug] Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type FLOAT, timestamp 1737611978558, value 10.0]

### Search before asking

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

### Version

dev-1.3 版本，2025-01-2217点拉取、编译生产的；

### Describe the bug and provide the minimal reproduce step

1. 首先我要导入一个表数据；
- 表结构如下：

```shell
IoTDB> show nodes in schema template test
+----------+---------+----------+-----------+
|ChildNodes| DataType| Encoding|Compression|
+----------+---------+----------+-----------+
| name| STRING|DICTIONARY| LZ4|
| in_time|TIMESTAMP| TS_2DIFF| LZ4|
| device_id| INT64| TS_2DIFF| LZ4|
| thresold| STRING|DICTIONARY| LZ4|
| value| STRING|DICTIONARY| LZ4|
+----------+---------+----------+-----------+
```

2. 然后需要从一个csv文件导入到表内
- csv 文件内的数据如下：

```csv

Time,Device,name,in_time,device_id,thresold,value
2025-01-23T14:08:38.558+08:00,root.log.in,"device_name1234567890",1737612237512,10000001,"1","value_test_111"
2025-01-23T14:07:38.558+08:00,root.log.in,"device_name1234567891",1737612237512,10000002,"2","value_test_112"
2025-01-23T14:06:38.558+08:00,root.log.in,"device_name1234567892",1737612237512,10000003,"3","value_test_113"
2025-01-23T14:05:38.558+08:00,root.log.in,"device_name1234567893",1737612237512,10000004,"4","value_test_114"
2025-01-23T14:04:38.558+08:00,root.log.in,"device_name1234567894",1737612237512,10000005,"5","value_test_115"
2025-01-23T14:03:38.558+08:00,root.log.in,"device_name1234567895",1737612237512,10000006,"6","value_test_116"
2025-01-23T14:02:38.558+08:00,root.log.in,"device_name1234567896",1737612237512,10000007,"7","value_test_117"
2025-01-23T14:01:38.558+08:00,root.log.in,"device_name1234567897",1737612237512,10000008,"8","value_test_118"
2025-01-23T14:00:38.558+08:00,root.log.in,"device_name1234567898",1737612237512,10000009,"9","value_test_119"
2025-01-23T13:59:38.558+08:00,root.log.in,"device_name1234567899",1737612237512,10000010,"10","value_test_120"

```
3. 再shell终端导入

```shell

root@IOT:/usr/local/iotdb/tools# ./import-data.sh -u root -pw '密码' -s /home/dump0_0.csv -aligned true -file_type csv -ty ms
Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type DOUBLE, timestamp 1737611978558, value 1.737612237512E12]

```
- 哦，对了，-file_type参数，不是type参数，使用type参数不行

4. 难道需要转换下格式？

```shell
# 加双引号报错：
Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type STRING, timestamp 1737611978558, value 1737612237512]

# 加单引号报错：
Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type STRING, timestamp 1737611978558, value '1737612237512']

# 使用date 报错：

Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type STRING, timestamp 1737611978558, value 2025-01-23T14:08:38.558]

```

### What did you expect to see?

# waiting

### What did you see instead?

# waiting

### Anything else?

# no

### Are you willing to submit a PR?

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

Reproduce the failure with tools/import-data.sh using the CSV command and the TIMESTAMP column shown in the issue. Trace the CSV import path from that script and inspect how the -ty ms option parses numeric timestamp values versus TIMESTAMP schema fields. Done means the sample CSV imports successfully without a type-mismatch error, with the intended timestamp values preserved.

Written by the indexing model from the issue text.