[Improvement]: ExternalType.catalogString() is written verbatim into DDL SQL without validation in JDBC catalog

## What would you like to be improved?

In `MysqlTypeConverter`, `PostgreSqlTypeConverter`, and `DorisTypeConverter` (added in #11763), `fromGravitino(ExternalType)` returns `type.catalogString()` directly. This string is then inserted verbatim into `CREATE TABLE` / `ALTER TABLE` SQL in the corresponding `TableOperations` class (e.g. `DorisTableOperations:630`, `:744`, `MysqlTableOperations`, `PostgreSqlTableOperations`).

There is no validation that `catalogString()` is a well-formed, single-token type name. An authenticated API caller who stores an `ExternalType` with a malformed or multi-statement string (e.g. `ExternalType.of("json; DROP TABLE foo")`) would have that string embedded directly into the generated DDL.

**Affected files:**
- `catalog-jdbc-mysql`: `MysqlTypeConverter.fromGravitino`
- `catalog-jdbc-postgresql`: `PostgreSqlTypeConverter.fromGravitino`
- `catalog-jdbc-doris`: `DorisTypeConverter.fromGravitino`

## How should we improve?

Add a shared validation helper in `JdbcTypeConverter` (or override the base `fromGravitino` contract) that rejects `catalogString()` values containing SQL metacharacters (e.g. semicolons, quotes, comment markers) before they reach DDL construction.

Alternatively, maintain a per-catalog allowlist of known valid external type names and reject anything not on the list.

This can be done as a follow-up hardening task independent of any specific connector PR.

Start by reading JdbcTypeConverter and the fromGravitino methods in MysqlTypeConverter, PostgreSqlTypeConverter, and DorisTypeConverter, then trace the affected TableOperations DDL paths named in the issue. Check the existing JDBC connector tests and add coverage showing malformed catalogString values are rejected before CREATE TABLE or ALTER TABLE SQL is built.

Written by the indexing model from the issue text.