[Bug report] Doris catalog misclassifies native NGRAM_BF index metadata

### Version

main branch

### Describe what's wrong

When the Doris catalog loads a table containing a native NGram BloomFilter index, Doris reports `Index_type=NGRAM_BF`, but Gravitino maps the metadata to an unrelated existing index type. An ordinary index name falls through the generic unknown-index fallback and is exposed as `IndexType.INVERTED`, while an index named `PRIMARY` is intercepted by the legacy name mapping and is exposed as `IndexType.PRIMARY_KEY`. Neither result represents the native index, and the `gram_size` and `bf_size` properties are not represented.

Expected behavior: until Gravitino has an accepted NGRAM_BF representation and property contract, loading the table should fail with a clear unsupported-operation error that identifies the index name and native type.

Actual behavior: the table load succeeds and returns a fabricated INVERTED index with an empty property map for an ordinary index name, or a fabricated PRIMARY_KEY index when the native index is named `PRIMARY`.

### Error message and/or stacktrace

No exception is raised. The incorrect metadata is observable as:

```text
Doris SHOW INDEX: Index_type=NGRAM_BF
Gravitino Table.index() with an ordinary index name: type=INVERTED, properties={}
Gravitino Table.index() with Key_name=PRIMARY: type=PRIMARY_KEY, properties={}
```

### How to reproduce

1. Build Gravitino from the main branch and configure a JDBC Doris catalog against Doris 3.0.6.2 or 4.0.6.
2. Create a Doris table with a string column.
3. Create a native NGRAM_BF index:

```sql
CREATE INDEX `idx_ngram_bf` ON `table_name` (`text_column`) USING NGRAM_BF PROPERTIES("gram_size"="3", "bf_size"="256");
SHOW INDEX FROM `table_name`;
```

4. Load the table through the Gravitino Doris catalog and inspect `Table.index()`.

### Additional context

Doris 3.0.6.2 and 4.0.6 both expose NGRAM_BF as a distinct native index type. The Doris read path also has legacy handling for `Key_name=PRIMARY`, so exact NGRAM_BF detection must take precedence even when a native NGRAM_BF index is named `PRIMARY`.

This issue is limited to preventing semantic misclassification. It does not add a public index enum, CREATE TABLE or ALTER support for NGRAM_BF, or `gram_size` and `bf_size` property round-trip support. Existing known mappings and the generic fallback for unrelated unknown index types should remain unchanged.

Start with the Doris catalog read path and the Table.index() entry point, then reproduce the NGRAM_BF case using the provided CREATE INDEX and SHOW INDEX SQL. Done means native NGRAM_BF loading fails with a clear unsupported-operation error naming the index and native type, while existing mappings and unrelated unknown-index fallback remain unchanged.

Written by the indexing model from the issue text.