[Bug]: non-strict VARCHAR truncation emits no 1265 warning over JDBC or SHOW WARNINGS

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

- [x] I searched open and closed issues and fix PRs.

Related but not a duplicate:

- #25200 fixed string-width assignment behavior and was closed. Its maintainer explicitly noted that truncation warnings were outside that fix and should be tracked by a separate issue.
- #26762 added the current end-to-end warning diagnostics path for other conversion cases, but non-strict string-width truncation still does not append a warning.

Searches included `Data truncated sql_mode`, `varchar truncation warning JDBC`, `warning count truncation`, and `jdbcCompliantTruncation`.

### Branch Name

main

### Commit ID

`493ab8a9585576b76508d054fef58ccb55c206c5`

### Other Environment Information

- MatrixOne was built from the exact current `origin/main` commit above.
- MySQL control: 8.0.46.
- MySQL Connector/J: 8.0.33 and 26.7.0.
- Server-side PreparedStatement was forced with `useServerPrepStmts=true`, `cachePrepStmts=false`, and `emulateUnsupportedPstmts=false`.

### Actual Behavior

With non-strict `sql_mode`, MatrixOne correctly truncates an over-length value assigned to `VARCHAR(4)` and stores `abcd`, but it reports no warning:

```text
PreparedStatement.getWarnings(): 0 warnings
SHOW WARNINGS: 0 rows
```

The same result occurs for a plain Statement insert. Connector/J 8.0.33 and 26.7.0 each reproduced this 3/3.

The original server PreparedStatement remains reusable after the truncating insert, and a subsequent valid insert stores the exact value.

MySQL 8.0.46 control, with the same table and SQL mode:

```text
PreparedStatement.getWarnings(): 1 warning
SHOW WARNINGS: 1 row, code 1265
```

The plain Statement path also returns one 1265 warning. Both Connector/J versions reproduced the control result 3/3.

### Expected Behavior

When non-strict assignment truncates an over-length string, MatrixOne should:

- keep the current truncated stored value;
- append warning 1265 (`01000`, Data truncated for column);
- put warning count `1` in the OK packet so JDBC `Statement.getWarnings()` can expose it;
- return the same diagnostic from `SHOW WARNINGS`.

### Steps to Reproduce

```sql
SET SESSION sql_mode = '';
CREATE TABLE t(id INT PRIMARY KEY, v VARCHAR(4));
```

Then use a real server PreparedStatement for:

```sql
INSERT INTO t VALUES (?, ?)
```

Bind `(1, 'abcdef')`, execute, call `PreparedStatement.getWarnings()`, then execute `SHOW WARNINGS` and read back `v`.

MatrixOne stores `abcd` but exposes no warning. MySQL stores `abcd` and exposes warning 1265.

### Root Cause

`pkg/sql/plan/function/func_cast.go` routes DML assignment through `NewAssignCast`. In the CHAR/VARCHAR over-length branch, non-strict mode calls `truncateStringByRunes` and continues, but does not append a warning diagnostic.

The current warning pipeline is already able to reach the frontend and protocol response: `AppendWarningDiagnostic` / `AppendWarningBatch` and response warning counts are present, and other numeric coercion paths use them. The width-truncation branch is not connected to that pipeline.

### Consistency and Recovery Checks

- Latest official `main`: reproduced 3/3 per driver version.
- MySQL control: passed 3/3 per driver version.
- Each truncating statement inserted exactly one row with the expected truncated value.
- Same PreparedStatement recovery inserted a valid row correctly.
- Temporary objects were removed after every matrix.