[Bug]: temporal-expression CTAS columns retain microseconds but report DATETIME(0)

## Summary

CTAS columns derived from fractional temporal expressions can retain microseconds while exposing themselves as `DATETIME(0)`. `SHOW CREATE TABLE`, `information_schema.columns.COLUMN_TYPE`, `DATETIME_PRECISION`, result formatting, and accepted insert precision no longer describe one coherent column type.

This affects expressions whose static result type already carries scale 6, including `ADDTIME`, `SUBTIME`, `GREATEST`, and `LEAST`; it is distinct from the unscaled static return type already tracked for `DATE_ADD` / `DATE_SUB` in #28122.

## Environment

- MatrixOne official `main`: `e7bb0572235ec4bac81eb098eb0ad8900f0065ab`
- Clean local single-CN build and isolated data directory
- MySQL 8.3 comparison instance
- Reproduced identically in 3/3 reads

## Reproduction

```sql
CREATE DATABASE ctas_fsp_meta;
USE ctas_fsp_meta;

CREATE TABLE src (
id INT PRIMARY KEY,
dt DATETIME(6),
d DATE
);
INSERT INTO src VALUES
(1, '2024-01-01 01:02:03.123456', '2024-01-01'),
(2, '2024-01-02 02:03:04.654321', '2024-01-02');

CREATE TABLE c_addtime AS
SELECT ADDTIME(dt, '00:00:00.000001') AS v FROM src;

SHOW CREATE TABLE c_addtime;

SELECT DATA_TYPE, COLUMN_TYPE, DATETIME_PRECISION
FROM information_schema.columns
WHERE table_schema = 'ctas_fsp_meta'
AND table_name = 'c_addtime'
AND column_name = 'v';

SELECT v, MICROSECOND(v), DATE_FORMAT(v, '%f') FROM c_addtime ORDER BY v;

INSERT INTO c_addtime VALUES ('2031-07-08 09:10:11.654321');
SELECT v, MICROSECOND(v), DATE_FORMAT(v, '%f')
FROM c_addtime WHERE v >= '2031-01-01';
```

## Actual behavior

```text
SHOW CREATE TABLE:
`v` datetime DEFAULT NULL

information_schema.columns:
DATA_TYPE = datetime
COLUMN_TYPE = DATETIME(0)
DATETIME_PRECISION = 6

CTAS values:
2024-01-01 01:02:03.123457 | 123457 | 123457
2024-01-02 02:03:04.654322 | 654322 | 654322

Subsequent insert:
2031-07-08 09:10:11.654321 | 654321 | 654321
```

The column stores and returns six fractional digits, but both the persisted DDL and `COLUMN_TYPE` identify it as `DATETIME(0)`. `DATETIME_PRECISION` independently reports 6.

The same metadata contradiction occurs with:

```sql
CREATE TABLE c_subtime AS
SELECT SUBTIME(dt, '00:00:00.000001') AS v FROM src;

CREATE TABLE c_greatest AS
SELECT GREATEST(dt, d) AS v FROM src;

CREATE TABLE c_least AS
SELECT LEAST(dt, d) AS v FROM src;
```

Plain-column CTAS, explicit `CAST(dt AS DATETIME(6))`, and `COALESCE(dt, CAST(NULL AS DATETIME(6)))` preserve `DATETIME(6)` consistently, so this is not a general CTAS formatting limitation.

MySQL 8.3 declares all four target columns as `DATETIME(6)` and reports `COLUMN_TYPE=datetime(6)`, `DATETIME_PRECISION=6`.

## Expected behavior

The persisted CTAS schema and all metadata surfaces should describe the actual six-digit temporal precision:

```text
SHOW CREATE TABLE: datetime(6)
COLUMN_TYPE: datetime(6)
DATETIME_PRECISION: 6
```

Clients should not receive a `DATETIME(0)` column descriptor for values that contain fractional seconds.

## Code observation

The affected function return-type paths construct a `DATETIME` carrying scale 6, and the runtime result vectors also retain that scale. The inconsistency appears while the function result type is converted into the persisted CTAS column definition and later rendered through DDL / information schema metadata.