[Bug]: TIMESTAMPDIFF panics on MICROSECOND Time Window boundaries

### Is there an existing issue for the same bug?

- [x] I have checked the existing issues.

### Branch Name

main

### Commit ID

a1e161ad3e0fc83cabfc66db8b4d5419d16c9ee4

### Other Environment Information

```Markdown
- Hardware parameters: Apple Silicon, 8 logical cores
- OS type: macOS arm64
- Deployment: standalone launch.toml and launch-with-proxy.toml (2 CN + proxy)
- Client: MySQL protocol on 127.0.0.1:6001
```

### Actual Behavior

The query returns ERROR 20101 and an internal panic stack instead of a result. The panic is reproducible on the generated _wstart and _wend Time Window boundary columns:

~~~text
ERROR 20101 (HY000): internal error: panic type mismatch: casting TIMESTAMP vector to []types.Datetime
~~~

The server remains reachable after the failed statement, but the supported query path is rejected by an internal panic.

### Expected Behavior

TIMESTAMPDIFF should return the microsecond width of each generated window (for the example below, 1000) without an internal error or panic. The behavior should be consistent with the existing DATETIME(6) Time Window boundary path.

### Steps to Reproduce

```Markdown
1. Start MatrixOne from the latest main with ./mo-service -launch ./etc/launch/launch.toml and connect through MySQL protocol.
2. Execute:

~~~sql
DROP DATABASE IF EXISTS issue26983_diff;
CREATE DATABASE issue26983_diff;
USE issue26983_diff;
CREATE TABLE ts_hf (
event_ts TIMESTAMP(6),
device_id BIGINT,
value DOUBLE
);
INSERT INTO ts_hf VALUES
('2026-08-12 10:00:00.000100', 1, 10),
('2026-08-12 10:00:00.000900', 1, 20),
('2026-08-12 10:00:00.001100', 1, 30);
SELECT TIMESTAMPDIFF(MICROSECOND, _wstart, _wend) AS width_us
FROM ts_hf
INTERVAL(event_ts, 1000, MICROSECOND);
~~~
3. Repeat the final SELECT three times.
```

### Additional information

## Stability and controls

- Reproducer: 3/3 failures on the same build; the same failure was also observed through the 2-CN proxy deployment.
- Normal control: TIMESTAMPDIFF(MICROSECOND, event_ts, event_ts) on the base TIMESTAMP(6) column returns 0 normally. The original MICROSECOND Time Window aggregation also returns the expected two rows (2/15 and 1/30).
- Data state: the source table remains queryable and contains all 3 inserted rows after each failed statement.

## Evidence

The stack enters pkg/container/vector/vector.go:166 through vector.ToSlice/vector.ToFixedCol, with the attempted cast from a TIMESTAMP vector to []types.Datetime.

## Regression coverage

Add a distributed SQL regression covering TIMESTAMP(6) and DATETIME(6) Time Window boundaries with TIMESTAMPDIFF, plus a no-panic assertion for generated _wstart/_wend columns.

## Related

This was found while validating [#26983](https://github.com/matrixorigin/matrixone/issues/26983), which introduced MICROSECOND Time Window support. The original MICROSECOND aggregation path is fixed; this report tracks the separate boundary-type panic.