Bug: Unknown index type in TableIndexType causes hard Incompatible failure on older Databend versions

[zhang2014]

Description

TableIndexType is an enum with explicit discriminant values and num_derive::FromPrimitive. The proto-conv deserialization path
(meta/proto-conv/src/impls/table.rs:437) converts via:

FromPrimitive::from_i32(...).ok_or(Incompatible)

When a table declares an index type that an older binary does not recognize, deserialization fails hard with Incompatible rather than
skipping the unknown index. The entire table metadata becomes unreadable.

Impact

• Once a table enables a new index type (e.g. Bloom), any Databend version predating that feature cannot access the table at all — not just
  the new index, but any operation requiring meta deserialization.
• This is not unique to the current proposal: Vector=2 and Spatial=3 exhibit the same behavior when read by older binaries. It is a
  pre-existing gap in the proto-conv reader-version mechanism.

Root Cause

from_pb uses a fail-hard strategy for unknown enum variants. There is no fallback path to skip or mark unrecognized index types as
unavailable.

Expected Behavior

• Data file layer (sidecar / payload files): already fully bi-directionally compatible, no change needed.
• Table metadata layer: older versions encountering an unknown index type should degrade gracefully — skip the unknown index or mark it as
  unavailable — so that table reads and known-index operations remain functional.

Additional Note on Payload Format

Payload files are standard Parquet files. The [offset, len) recorded in the sidecar points to a complete data page (including page header),
not raw FilterImpl bytes. The pruning read path should read the page bytes at the sidecar offset, decode via standalone page deserialization
to recover Binary values, reusing the existing read_block_context "partial chunk independent decode" pattern.

Steps to Reproduce

1. On a newer Databend version, create a new index type (e.g. Bloom) on a table.
2. Connect an older Databend version (predating the feature) to the same meta store.
3. Perform any read operation on that table → Incompatible error.

[vismaytiwari]

Hey — I was able to reproduce this: a TableMeta carrying a single index with an unrecognized index_type fails from_pb with invalid IndexType: 9999, which makes the whole table metadata unreadable rather than just skipping that one index. Opened #20115 — it skips indexes whose type isn't recognized in TableMeta::from_pb so the rest of the metadata still loads, with a regression test for the unknown-discriminant case. Recognized indexes and other incompatibilities are untouched.