fix: fix time instant

[mengnankkkk]

What this PR does / why we need it?

Close #4003
在 ObjectWriterImplInstant.java 中，当 dateFormat 为 null 时，代码会直接调用 jsonWriter.writeInstant 并返回，导致后续的 ISO8601 格式检查逻辑永远不会执行

Summary of your change

Please indicate you've done the following:

• Made sure tests are passing and test coverage is added if needed.
• Made sure commit message follow the rule of Conventional Commits specification.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

[wenshao]

单测跑不过，merge from main分支试下

[wenshao]

感谢修复！核心思路是对的——移除 dateFormat == null 的提前返回，确保 ISO8601 等格式标志不被跳过。unixtime/millis 路径直接用 instant.toEpochMilli() 避免无意义的 ZonedDateTime 中转，也是不错的优化。

有几点建议：

1. 默认场景的性能回退

无格式配置是 Instant 最常见的使用场景。原来在第 40 行就直接返回了，现在会多走一遍 yyyyMMddhhmmss 检查、创建 ZonedDateTime、检查 ISO8601、获取 formatter，最终才调用 writeInstant(instant)。

建议在 unixtime/millis 检查之后加回一个更精确的快速路径：

if (dateFormat == null
&& !formatISO8601 && !context.isDateFormatISO8601()
&& !yyyyMMddhhmmss14 && !yyyyMMddhhmmss19
&& !yyyyMMdd8 && !yyyyMMdd10) {
jsonWriter.writeInstant(instant);
return;
}

这样既不会跳过格式标志，又保留了常见场景的快速路径。

2. 测试补充

• 当前测试全部使用 ZoneId.of("UTC")，但 writeInstant 和 writeZonedDateTime 在 UTC 下输出完全相同，无法验证兜底逻辑从 writeZonedDateTime 改为 writeInstant 的行为变更。建议增加一个非 UTC 时区（如 Asia/Shanghai）的测试用例。
• unixtime 和 millis 格式路径被移动并优化了，建议也补充对应的测试。