[Bug report] Trino connector still fails to read MySQL TIME/DATETIME/TIMESTAMP columns with fractional seconds precision

### Version

main branch

### Describe what's wrong

#6657 made the MySQL catalog report the fractional seconds precision of TIME/DATETIME/TIMESTAMP columns, but the Trino connector never picked it up: `MySQLDataTypeTransformer.getTrinoType` still maps every Gravitino TIMESTAMP to Trino `timestamp(0)` (or `timestamp(0) with time zone`) and every TIME to `time(0)`, regardless of the precision carried by the Gravitino type.

The internal Trino MySQL connector produces pages with the real column precision, so the declared type and the page type disagree, and `SELECT` on any DATETIME(p)/TIMESTAMP(p)/TIME(p) column with p > 0 fails.

This is the Trino side of #6656, which was closed by #6657 without touching the connector. #8216 later only changed the reverse direction (`getGravitinoType`).

### Error message and/or stacktrace

```
Could not serialize column 'created_at' of type 'timestamp(0)'
Caused by: java.lang.IllegalArgumentException: Expected 0s for digits beyond precision 0: epochMicros = 1679540780487000
at io.trino.spi.type.SqlTimestamp.newInstance
at io.trino.spi.type.ShortTimestampType.getObjectValue
```

### How to reproduce

1. In MySQL: `CREATE TABLE t (id INT, created_at DATETIME(6)); INSERT INTO t VALUES (1, '2025-07-04 14:30:00.123456');`
2. Create a jdbc-mysql catalog in Gravitino and load it in Trino through the Gravitino connector (MySQL Connector/J >= 8.0.16 on the Gravitino server so the precision is reported).
3. `SHOW CREATE TABLE` shows `created_at` as `timestamp(0)`; `SELECT * FROM t` fails with the error above.

### Additional context

Expected: the column is exposed as `timestamp(6)` and the query succeeds, matching the native Trino MySQL connector and the PostgreSQL transformer in this repo, which already maps the precision.

The write direction has the same problem: `getGravitinoType` forces precision 0 (kept from #8216), so tables created through Trino silently lose the requested precision, and CTAS from a `timestamp(6) with time zone` column fails with a block type mismatch. The native Trino MySQL connector (435 through 478) maps the precision exactly in both directions; MySQL is the only catalog in the Gravitino Trino connector whose mapping diverges from the native connector. Passing the precision through on the write side also requires the MySQL catalog to render `CURRENT_TIMESTAMP(p)` default values, since MySQL rejects `DATETIME(6) DEFAULT CURRENT_TIMESTAMP`.

Start at MySQLDataTypeTransformer.getTrinoType and compare its timestamp and time mapping with the PostgreSQL transformer and native Trino MySQL connector behavior. Trace getGravitinoType and the MySQL catalog's CURRENT_TIMESTAMP default rendering as well. Done means fractional precision is preserved in both read and write directions, SHOW CREATE TABLE reports it correctly, and the reproduced DATETIME(6) query succeeds.

Written by the indexing model from the issue text.