[Compatibility]: div_precision_increment is accepted but ignored by DECIMAL division

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

- [x] I have checked the existing issues, including open and closed issues.

### Branch Name

main

### Commit ID

fc621e3616d229c7a29d0c80e73ed8eb1997459c

### Other Environment Information

- MatrixOne: locally built from the commit above (`8.0.30-MatrixOne-v1.3.0`)
- MySQL baseline: 8.0.46
- Verification date: 2026-09-10

### Actual Behavior

MatrixOne exposes `div_precision_increment` as a dynamic global/session variable and accepts new session values, but the variable has no effect on exact DECIMAL division. The quotient value, number of fractional digits, result precision/scale, CTAS schema, and prepared execution remain fixed after the variable changes.

For `DECIMAL(10,2) / DECIMAL(10,2)`, MatrixOne always returns eight fractional digits and CTAS always creates `DECIMAL(38,8)`:

```text
div_precision_increment MatrixOne value MatrixOne CTAS type
0 0.33333333 DECIMAL(38,8)
4 0.33333333 DECIMAL(38,8)
10 0.33333333 DECIMAL(38,8)
30 0.33333333 DECIMAL(38,8)
```

`SELECT @@session.div_precision_increment` does report `0`, `4`, `10`, and `30` after each `SET`, so the setting is stored but not consumed by division.

MySQL 8.0.46 applies the same setting to both value precision and metadata:

```text
div_precision_increment MySQL value MySQL CTAS type
0 0.33 DECIMAL(12,2)
4 0.333333 DECIMAL(16,6)
10 0.333333333333 DECIMAL(22,12)
30 0.333333333333333333333333333333 DECIMAL(42,30)
```

The mismatch also affects Decimal256 input. With `DECIMAL(50,10) / 3`, MatrixOne always returns scale 12 and CTAS always creates `DECIMAL(65,12)`, while MySQL uses scales 10, 14, 20, and 30 for increments 0, 4, 10, and 30 respectively (subject to its maximum DECIMAL precision when materialized).

This is not a harmless display difference: changing the setting is expected to control how many division digits survive, and persisted expression schemas inherit the result metadata.

### Expected Behavior

`div_precision_increment` should participate in exact DECIMAL division type derivation and evaluation as it does in MySQL. Changing the session value should change the quotient scale and derived CTAS/view metadata for subsequent statements.

If MatrixOne does not intend to support the setting, it should not expose it as a writable dynamic compatibility variable whose accepted value is silently ignored.

### Steps to Reproduce

```sql
DROP DATABASE IF EXISTS div_precision_repro;
CREATE DATABASE div_precision_repro;
USE div_precision_repro;

SET SESSION div_precision_increment=0;
SELECT @@session.div_precision_increment;
SELECT CAST(
CAST(1 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2))
AS CHAR
);
CREATE TABLE d0 AS
SELECT CAST(1 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2)) AS q;
SHOW CREATE TABLE d0;

SET SESSION div_precision_increment=4;
SELECT @@session.div_precision_increment;
SELECT CAST(
CAST(1 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2))
AS CHAR
);
CREATE TABLE d4 AS
SELECT CAST(1 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2)) AS q;
SHOW CREATE TABLE d4;

SET SESSION div_precision_increment=10;
SELECT CAST(
CAST(1 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2))
AS CHAR
);

SET SESSION div_precision_increment=30;
SELECT CAST(
CAST(1 AS DECIMAL(10,2)) / CAST(3 AS DECIMAL(10,2))
AS CHAR
);
```

### Additional information

`pkg/frontend/variables.go` registers `div_precision_increment` as a dynamic `ScopeBoth` integer variable with MySQL's default value 4. No other production code references the variable. The `/` DECIMAL return-type logic in `pkg/sql/plan/function/list_operator.go` instead derives a fixed scale around 12 from operand scales, so session state cannot influence either the result type or evaluator.

Decimal128 and Decimal256 operands, values 0/4/10/30, direct SELECT, CTAS and information-schema metadata were reproduced three times on the same latest-main build. No existing issue for `div_precision_increment` or this DECIMAL division behavior was found.