perf(scan): reuse index planning resources across queries

[wangyong9999]

Purpose

Linked issue: N/A

Repeated DataEvolution/global-index scans in one process rebuilt immutable planning state and
discarded BTree pages after each reader was destroyed. This made repeated point lookups spend most
of their time in planning and index I/O.

DataEvolutionBatchScan now reuses the TableSchema, CoreOptions, filesystem, executor,
memory pool, and caller-provided cache already initialized by TableScan. The index scan is still
created for the exact requested snapshot.

BTree indexers with the same cache configuration share immutable pages across reader instances.
The process retains at most four cache configurations, and active readers keep an evicted manager
alive only for their own lifetime. Page keys include a backend namespace; filesystem-backed readers
share by filesystem instance, while unknown reader implementations remain isolated. Input streams
are opened only on a cache miss.

Bucket-scoped manifest cache entries now require both the snapshot ID and its base/delta
manifest-list generation to match. Whole-table and row-range scans do not use this cache. Cache
load/deserialize/store failures continue to rebuild from manifests.

The shared-cache registry mutex covers only manager lookup/creation. Page access continues through
the existing thread-safe bounded LRU. The eager BlockCache constructor and Close() behavior are
unchanged.

On an HDFS primary-key table with 606K rows, 51 active files, and 6.5 GB of data, a logid lookup
returning two rows changed from 851/163/1015 ms plan/read/total on the cold run to 115/99/214 ms on
the second run in the same process. BTree evaluation changed from 621 ms to 0.55 ms. Both runs
selected one indexed split, one data file, and a two-row range, and matched an index-disabled scan.

Tests

• Debug CMake build with tests, Avro, and ORC enabled.
• paimon-common-test: 1,497 passed.
• paimon-common-sst-file-format-test: 33 passed.
• paimon-core-test: 1,862 passed.
• paimon-primary-key-sorted-index-inte-test: 12 passed, including the previously failing
  Parquet and ORC multi-source ordinal cases.
• paimon-global-index-test: 132 passed.
• Targeted cache tests cover same-backend reuse, different-backend isolation, retained-page reuse,
  cache-key namespace separation, and snapshot generation validation.
• Two-query native-HDFS validation: validation status=PASS,
  path_proof status=PASS path=pk-file-local-btree.
• clang-format 20.1.8, cpplint 2.0.2, codespell 2.4.1, and git diff --check pass on the changed
  files.

GitHub Actions for the latest fork commit are waiting for maintainer approval.

API and Format

Adds an overload of CacheKey::ForPosition that accepts an internal backend namespace. This is an
additive API change. There is no object-layout, table storage-format, or protocol change. The
process-local snapshot cache serialization version changes; older cached bytes fail validation and
are rebuilt.

Documentation

No new user-facing option or feature.

Generative AI tooling

Generated-by: Codex (GPT-5)

[wangyong9999]

The failure came from process-wide BTree pages warmed by an earlier fixture. The cache key now includes the backend namespace, so cross-fixture pages cannot be reused. I restored the exact file-open assertion; all 12 primary-key sorted-index integration cases pass for Parquet and ORC. The latest fork workflows are waiting for maintainer approval.