fix(table): resolve index files by external path and bucket layout

[JunRuiLee]

What

Index files are always read from <table>/index/<file>, which ignores two things Java records and
honors:

• _EXTERNAL_PATH — IndexFileMeta.SCHEMA field 5. Not decoded here at all, so it is also dropped
  when this crate rewrites an index manifest.
• index-file-in-data-file-dir — when set, Java's indexFileFactory(partition, bucket) resolves an
  index file against the bucket's data-file directory instead of the table index/ directory.

Either one makes a table's index files unreadable. Observed as a primary-key vector search:
failed to open ANN index file '.../<table>/index/index-<uuid>-0' for range reads, while the file is
in the bucket directory.

How

Decode _EXTERNAL_PATH and add it to the write schema, add the index-file-in-data-file-dir option,
and route every index-file consumer through one resolver (table/index_file_path.rs) with two modes,
each mirroring the factory Java uses for that consumer:

mode	consumers	Java
global — always <table>/index	data-evolution global index, vector and full-text search over it	globalIndexFileFactory()
bucket-local — data-file directory when the option is set	primary-key vector ANN segments, primary-key full-text archives, deletion vectors, dynamic-bucket hash index	pathFactories.get(partition, bucket)

An explicit external path wins over both layouts, as in toPath(IndexFileMeta).

For the two index kinds this crate writes itself, reads and writes move together, so a file written
here is found again: the data-evolution writer resolves an existing deletion vector through the same
path when merging and writes a new one where the reader will look; the dynamic-bucket assigner resolves
per partition and bucket for both restore and commit (prepare_commit_index no longer takes an index
directory — three of its four implementations ignored it); and TableCommit::abort deletes where the
file was written, mirroring FileStoreCommitImpl.abort. Deleting is best-effort, so the old fixed path
leaked silently — and try_commit calls abort itself on failure, as do the C and Python bindings.

Bucket directories now come from one spec::bucket_path (Java FileStorePathFactory.bucketPath),
replacing four copies of the same expression: the layout is only correct while every producer and
consumer agrees byte for byte, and nothing else enforces that.

Two smaller consequences of making the option live:

• It is now immutable, as in Java (@Immutable, rejected by SchemaManager.checkAlterTableOption).
  It selects where index files are written, so flipping it on a populated table would hide every index
  file the table has. It was inert here before, so altering it used to be a harmless no-op.
• $physical_files_size counts an index- prefixed file in a bucket directory as an index file
  instead of dropping it, matching Java FileType.classify. Classification follows physical form, not
  the current option value. Two tests that asserted the old counts are corrected.

The BTree reader cache is keyed by the resolved path — with the bare file name, two entries sharing a
name but resolving to different locations would reuse each other's reader.

Out of scope

• data-file.path-directory: unsupported crate-wide (bucket paths are rooted at the table for data
  files as much as index files), so honoring it belongs with data-file path handling.
• Writing bucket-local index files to a configured external data path: this crate does not write
  data files there either. Reading a Java-written external index file works.
• Referenced-file identity: index files are keyed by bare file name, as Java does in the
  higher-stakes direction (LocalOrphanFilesClean maps candidate deletions by Path.getName()), and
  all names are UUID-based, so collisions are not reachable.

Behavior change

A table created with the option set but written only by older paimon-rust has its index files under
<table>/index, because this crate ignored the option — such a table is already unreadable by Java.
After this PR Rust agrees with Java. No compatibility fallback on purpose: one would diverge from Java
and mask genuine missing-file errors.

Testing

New: abort deletes an index file in the bucket data-file directory, and one at an external path (both
verified to fail against the old path); ANN segment and full-text archive resolution with the option
set, through a real split whose bucket path is not derivable from the table root — the failure this PR
fixes, previously untested through a split; directory() agrees with resolve() in every mode; decode
tests for _EXTERNAL_PATH present, present-but-null, and absent from the writer schema; the option
cannot be altered.

Gates: cargo fmt --all -- --check clean; clippy -D warnings --all-targets clean for paimon,
paimon --features fulltext, paimon-datafusion, paimon-c (paimon-python needs Python ≥ 3.10,
unavailable locally); cargo test -p paimon --lib 2425 passed, 2500 with --features fulltext,
--tests all pass. paimon-datafusion 339 passed / 7 failed — all seven are TableNotExist for the
/tmp/paimon-warehouse fixtures that make docker-up provisions, unrelated to this change.

[JingsongLi]

• The abort() function in table_commit.rs:728-735 deletes all indexes lacking an external path as if they were BucketLocal.
• When index-file-in-data-file-dir=true is enabled, the global index is actually written to <table>/index, but the abort process attempts to delete it from the bucket directory; this causes a failed commit to leave behind orphan files.

[JunRuiLee]

Confirmed, and reachable: the vindex index builder aborts messages holding global index files, and try_commit aborts whatever it was committing.

Fixed in 88f1df1. abort now classifies each index file rather than resolving the whole message as bucket-local:

• no _GLOBAL_INDEX → bucket-local (deletion vectors, the dynamic-bucket hash index);
• a _GLOBAL_INDEX whose _SOURCE_META is absent — what this crate's index builders write — or whose _SOURCE_META carries DataEvolutionIndexSourceMeta's DEIX marker → global;
• anything else → bucket-local, which is what Java assumes for every index file.

Both abort tests now also plant a same-named file in the other layout and assert it survives, so neither direction can regress into deleting a path the commit does not own.

One thing I ran into while checking this against Java: FileStoreCommitImpl.abort resolves every newIndexFiles() entry through IndexFilePathFactories.get(partition, bucket), while SortedGlobalIndexWriter.flushIndex writes through globalIndexFileFactory() and returns those metas in DataIncrement.indexIncrement(...). So with index-file-in-data-file-dir set, Java leaves the same orphan behind.