[Bug report] Doris UpdateColumnType fails for columns with existing default values

### Version

main branch

### Describe what's wrong

The JDBC Doris catalog fails to change the type of a column that already has a default value. `DorisTableOperations.updateColumnTypeFieldDefinition()` preserves the loaded column comment, nullability, and auto-increment state, but replaces the loaded default with `DEFAULT_VALUE_NOT_SET`.

Doris treats `MODIFY COLUMN` as a complete column definition and requires the submitted default to match the existing default. Omitting the existing default therefore causes an otherwise valid type widening to fail instead of changing only the requested type.

Expected behavior: `UpdateColumnType` should preserve the existing default expression and let Doris validate whether the new type and the preserved default are compatible.

Actual behavior: the generated `MODIFY COLUMN` clause omits the default, and Doris rejects the operation.

### Error message and/or stacktrace

```text
errCode = 2, detailMessage = Can not change default value
```

### How to reproduce

1. Configure a `jdbc-doris` catalog against Doris.
2. Create a table through Gravitino with a non-nullable `VARCHAR(10)` column whose default value is `seed`.
3. Call `TableCatalog.alterTable()` with `TableChange.updateColumnType()` to widen that column to `VARCHAR(20)`.
4. Observe that Doris rejects the generated `MODIFY COLUMN` statement because the existing default is omitted.

Representative API call:

```java
tableCatalog.alterTable(
tableIdentifier,
TableChange.updateColumnType(
new String[] {"col_data"}, Types.VarCharType.of(20)));
```

Expected result: the column type becomes `VARCHAR(20)` and its default remains `seed`.

Actual result: the operation fails with `Can not change default value`.

### Additional context

Doris validates a type change against a full replacement column definition. The connector already loads the existing default before generating the ALTER statement, so it can preserve that value through the existing Doris default-value converter without adding a parser or reimplementing Doris compatibility rules.

Issue #9816 and PR #9821 are related default-value serialization work, but they do not preserve an existing default during `UpdateColumnType`. Issue #3174 tracks generic asynchronous schema-change status and is outside the scope of this bug.

For nullable columns, Doris JDBC metadata may not preserve the textual distinction between an absent default and an explicit `DEFAULT NULL`. This fix should preserve the semantic default representation loaded by the connector rather than promise exact reconstruction of the original DDL text.

The fix should remain local to the Doris catalog: preserve the loaded default while building the replacement `JdbcColumn`, keep `DEFAULT_VALUE_NOT_SET` behavior for columns that genuinely have no default, and leave type/default compatibility validation to Doris.

Start in DorisTableOperations.updateColumnTypeFieldDefinition() and trace how the loaded JdbcColumn is converted into the MODIFY COLUMN definition. Reproduce the issue with TableCatalog.alterTable() and a non-nullable VARCHAR column whose default is seed. Done means the existing semantic default is preserved for columns that have one, DEFAULT_VALUE_NOT_SET remains for columns without one, and Doris accepts the type change.

Written by the indexing model from the issue text.