[Bug report] JDBC Doris ADD COLUMN drops default values

### Version

main branch

### Describe what's wrong

The JDBC Doris catalog accepts a default value in `TableChange.AddColumn`, but `DorisTableOperations.addColumnFieldDefinition()` does not include it in the generated `ALTER TABLE ... ADD COLUMN` statement.

For a non-nullable column, Doris may reject the schema change because the generated definition has no default. For a nullable column, the operation may succeed while silently discarding the requested default, so later inserts and `loadTable()` return behavior differ from the caller's request.

Expected behavior: Doris `ADD COLUMN` should preserve supported literal defaults and `CURRENT_TIMESTAMP`. At the SQL generation boundary, an explicit null default should emit `DEFAULT NULL`, while `DEFAULT_VALUE_NOT_SET` should omit the clause.

Actual behavior: the generated ADD COLUMN definition contains the type, nullability, comment, and position, but omits the requested default.

### Error message and/or stacktrace

Nullable columns may not produce an error and instead lose the requested default silently. As a separate impact, Doris can reject a non-nullable ADD COLUMN because the generated definition has no default.

Representative generated SQL:

```sql
ALTER TABLE `test_table`
ADD COLUMN `new_col` varchar(255);
```

The expected definition includes a `DEFAULT` clause before `COMMENT` and `FIRST`/`AFTER`.

### How to reproduce

1. Configure a `jdbc-doris` catalog against Doris.
2. Create a table through Gravitino.
3. Add a nullable column with a non-null default through `TableChange.addColumn()`.
4. Load the table or insert a row without specifying the new column and observe that the requested default was not preserved.
5. Separately, add a non-nullable column with a default and observe that Doris may reject the ADD COLUMN because the generated definition omits the default.

Representative API call:

```java
tableCatalog.alterTable(
tableIdentifier,
TableChange.addColumn(
new String[] {"new_col"},
Types.VarCharType.of(255),
null,
TableChange.ColumnPosition.defaultPos(),
true,
false,
Literals.of("default value", Types.VarCharType.of(255))));
```

### Additional context

`TableChange.AddColumn` already exposes `getDefaultValue()`, and other JDBC catalog implementations consume it when building ADD COLUMN SQL. The fix should remain local to the Doris catalog and leave type/default validation to Doris.

Doris default-literal parsing differs across supported versions, especially for backslashes in `ALTER TABLE ... ADD COLUMN`. The implementation should verify metadata round-trip and omitted-column INSERT semantics on the repository's Doris 1.2.x, 3.0.6.2, and 4.x baselines without changing CREATE TABLE or unrelated MODIFY COLUMN serialization.

Issue #839 and PR #2558 introduced AddColumn default support in the public API. Issue #9816 and PR #9821 addressed shared default serialization, but they do not make the Doris ADD COLUMN path consume `AddColumn.getDefaultValue()`.

For nullable columns, Doris/JDBC metadata may normalize both an absent default and an explicit `DEFAULT NULL` to `null`. The required distinction is therefore at SQL generation time; the issue does not require reconstructing their original textual difference from metadata.

Start at DorisTableOperations.addColumnFieldDefinition() and compare it with other JDBC catalog implementations that consume TableChange.AddColumn.getDefaultValue(). Verify the generated ADD COLUMN SQL for supported literal defaults, CURRENT_TIMESTAMP, explicit null, and DEFAULT_VALUE_NOT_SET, then check metadata round-trip and omitted-column inserts on the listed Doris baselines without changing CREATE TABLE or MODIFY COLUMN serialization.

Written by the indexing model from the issue text.