Purpose

Linked issue: close #1843

This PR fixes a precision handling bug in PojoToRowConverter where timestamp values were not being truncated according to the schema-defined precision when converting POJO objects to internal rows.

fix log

Problem:

• PojoToRowConverter did not respect the precision parameter defined in TIMESTAMP_WITHOUT_TIME_ZONE and TIMESTAMP_WITH_LOCAL_TIME_ZONE types when converting POJO fields to row values
• This caused an asymmetry with RowToPojoConverter, which correctly uses precision when reading values
• As a result, timestamp values could have higher precision than specified in the schema, violating the schema contract

Solution:

1. Modified createFieldConverter() in PojoToRowConverter to extract precision from DataType for timestamp fields
2. Updated convertTimestampNtzValue() and convertTimestampLtzValue() methods to accept and use precision parameter
3. Added three helper methods for precision truncation:
   • truncateToTimestampPrecision(LocalDateTime, int) - truncates LocalDateTime to specified precision
   • truncateToTimestampPrecision(Instant, int) - truncates Instant to specified precision
   • truncateNanos(int, int) - core truncation logic that calculates the divisor based on precision
4. Added comprehensive test cases to verify precision handling for different precision levels (3, 6, 9) and round-trip conversions

Tests

Unit Tests:

• PojoToRowConverterTest#testTimestampPrecision3 - Validates precision 3 (milliseconds) truncation
• PojoToRowConverterTest#testTimestampPrecision6 - Validates precision 6 (microseconds) truncation
• PojoToRowConverterTest#testTimestampPrecision9 - Validates precision 9 (nanoseconds) preserves full precision
• PojoToRowConverterTest#testTimestampPrecisionRoundTrip - Validates POJO → Row → POJO round-trip consistency